The Battle for Wesnoth Wiki - User contributions [en]

SoC Ideas SDL2

2014-02-12T20:41:01Z

SkeletonCrew: Created the SDL2 GSoC project

{{SoC2014Idea}}

=Description=
<h2>SDL2</h2>
Page for the idea: [[SoC_Ideas2014_Template]]

The Wesnoth project uses the SDL library, last year a new version (2.0) of
this library was released. This version of the library has better support
for mobile devices like the Android and the iPhone. This project involves
helping porting Wesnoth from SDL 1.2 to 2.0.

{{#dpl:
|resultsheader=''There are %PAGES% submitted student proposals for this idea''
|oneresultheader=''There is 1 submitted student proposal for this idea''
|suppresserrors=true
|noresultsheader=''There are no submitted student proposals for this idea''
|category=Summer of Code 2014 Student Page&SoC Ideas IDEA NAME
|notcategory=SoC 2014 Not Submitted To Google
|include=#Description
|nottitlematch=SoC2014_Template_of_Student_page
|mode=userformat
|format=,, See [[%PAGE%|%TITLE%]] for more information. ,
}}

=Additional Information=

The transition from SDL [1] 1.2 to 2.0 is a large project and a lot of work
needs to be done:
* The event handling has changed, so the event and input handling in Wesnoth needs to be changed.
* With SDL 1.2 we're using surface based drawing [2], with the transition to 2.0 we want use accelerated drawing [3].

The SDL transition is too large for one GSoC project, during the application period
the student will discuss which part of the transition he or she wants to work on
during the summer.

[1] http://libsdl.org/ 
[2] http://wiki.libsdl.org/CategorySurface 
[3] http://wiki.libsdl.org/CategoryRender 

=Whom to ask about this=

mordante on IRC

SoC Ideas SpriteSheets2014

2014-02-12T20:12:42Z

SkeletonCrew: Added spritesheet page

{{SoC2014Idea}}

=Description=
<h2>SpriteSheet</h2>
Page for the idea: [[SoC_Ideas2014_Template]]

Wesnoth uses a thousands of images, that are all stored in separate files.
It would be more efficient to store multiple images in a single file. In order
to make that possible the Wesnoth engine needs to be adapted to allow this change.

{{#dpl:
|resultsheader=''There are %PAGES% submitted student proposals for this idea''
|oneresultheader=''There is 1 submitted student proposal for this idea''
|suppresserrors=true
|noresultsheader=''There are no submitted student proposals for this idea''
|category=Summer of Code 2014 Student Page&SoC Ideas IDEA NAME
|notcategory=SoC 2014 Not Submitted To Google
|include=#Description
|nottitlematch=SoC2014_Template_of_Student_page
|mode=userformat
|format=,, See [[%PAGE%|%TITLE%]] for more information. ,
}}

=Additional Information=

Currently, all the Wesnoth unit animations are based on thousands of small png
images, each image representing the unit in a single pose. For terrains the
situation is the same, it has a base image with a lot of transitions to other
terrains, which are now stored as seperate images.

In a sprite sheet approach, each unit is represented by a single, huge, image
where all the unit images are put on a mosaïc pattern and the game knows where
to look for a given image.

The advantage of having a large image with all positions is that it's more
efficient in memory. Also one large file is more effecient on the harddisk and
faster to load than a lot of smaller files. So the change to spritesheets will
have a lot of advantages. Also several Wesnoth artists prefer using sprite
sheets over multiple single images.

This project involves changing the Wesnoth Markup Language (WML)* definition
for images to specify a sub image in a sprite sheet and change the image loading
code of the engine. Creating tools to transform existing images to a sprite sheet
can be an optional objective.

Regarding the implementation the student is free to come up with his/her own
solution and discuss that with the developers during the application period.

*) WML is a XML like language, used to describe the data/content of Wesnoth.

=Whom to ask about this=

mordante on IRC.

CodingStandards

2014-02-09T10:31:28Z

SkeletonCrew: Update the information regarding the C++ version Wesnoth uses

Wesnoth uses C++ that is portable to C++ compilers targeting various commonly used platforms.

== C++ version ==

Wesnoth uses C++ conforming to C++98/03. At the moment C++11 compiler support is still not widely available, therefore C++11 is not allowed.

== Formatting ==

When working on C++ for Wesnoth, indent your code with a tab character. After fully indenting, if you still need to line up the text with a specific character on the line above, you may further align it using space characters.

You may use long lines.

== Evil things to avoid ==

=== Avoid implicit conversions ===

Make all constructors which only take one argument that is of a different type to the class <tt>explicit</tt>.

Do not use <tt>operator T()</tt> (where <tt>T</tt> is a type) to allow an implicit conversion to a different type. For example:

t_string(const std::string&);

This can cause many situations where a temporary t_string is implicitly created and then gets destroyed unexpectedly (reference [https://gna.org/bugs/index.php?20360 bug #20360]).

=== Do not declare class data members as non-private ===

It's okay to have a ''struct'' with only public members, if that's what you want.

However, once something is a ''class'' with private data members, do not add public (or even protected) data members to the class. Doing this breaks encapsulation and can cause all kinds of confusing and evil things to happen.

== Naming ==

=== End non-public class data members with an underscore ===

All non-public data members of classes should have their names terminated with an underscore, to show that they are a class member. This makes for more readable code, once one is familiar with the convention.

== Idioms ==

=== Use references when a value may not be NULL ===

If a value passed to a function can never be <tt>NULL</tt>, use a reference instead of a pointer. For example:

void my_function(T& obj);

rather than

void my_function(T* obj);

This more clearly shows prospective users of the function that <tt>obj</tt> may never be <tt>NULL</tt>, without them having to consult documentation or the implementation of the function.

=== Use the const keyword ===

The <tt>const</tt> keyword in C++ allows interfaces to more clearly specify how they treat objects.
Always use <tt>const</tt> when you are not going to modify an object. For example:

void my_function(const T& obj);

This shows to the caller that <tt>obj</tt> will not be modified. If <tt>my_function()</tt> may modify <tt>obj</tt>, then use the following instead:

void my_function(T& obj);

Likewise, if a variable is not changed after initialization, make it <tt>const</tt>, and mark member functions as <tt>const</tt> if they do not modify their object.

=== Know the behavior of const references when types differ ===

If you assign something to a <tt>const</tt> reference of a different type, if necessary (if the type is different but there is a conversion) the compiler will create a temporary and guarantee it lasts for the lifetime of the reference. So

char c = 0;
const int& i = c;
c = 5;

will result in c == 5 and i == 0, which may not be what you expect.

=== Write exception-safe code ===

Wesnoth code should be exception-safe, even if you do not use exceptions directly. That is, you should be able to assume that an exception is thrown almost anywhere from within the code, with well-defined results (i.e. no resource leaks).

Code that uses a pattern like the following is bad:

{
SDL_Surface* image = IMG_Load("image.bmp");
...some code, which uses 'image'...
SDL_FreeSurface(image);
}

The code may throw an exception, and <tt>image</tt> will never be freed. Instead, use wrapper objects which free the object in their destructor.

For <tt>SDL_Surface</tt> objects, the <tt>surface</tt> type is used throughout the Wesnoth source code to achieve this purpose. So you could rewrite the above code as follows:

{
surface image(IMG_Load("image.bmp"));
...some code, which uses 'image'...
} ''the image is automatically freed here when 'image' is destroyed

Instead of allocating memory directly using <tt>new[]</tt> or <tt>malloc()</tt>, use language-provided containers, such as vector.

=== Do not use sprintf ===

The <tt>sprintf()</tt> function does not check whether or not it is writing past the end of the space allocated. This is a security problem if someone other than the person running the game can cause <tt>sprintf()</tt> to write very long strings. In Wesnoth, this untrusted data could come potentially from other players in a multiplayer game, or from downloaded add-ons. Instead you should use <tt>snprintf()</tt> with the second argument being the <tt>sizeof</tt> of the buffer that will hold the result.

== Standard C++ to avoid ==

=== Do not use wstring ===

The standard C++ <tt>std::wstring</tt> class (defined as a <tt>std::basic_string< wchar_t ></tt>) does not exist in some platforms supported by Wesnoth. Use <tt>wide_string</tt> instead (defined in <tt>language.hpp</tt>). The <tt>wide_string</tt> type is actually defined as <tt>std::vector< wchar_t ></tt>.

=== Do not use 0 when you mean NULL ===

Several Wesnoth developers, including Dave, find the number 0 to be very ambiguous when used in a non-numeric context. In keeping with the precedent that has already been established in the Wesnoth source code, you should avoid using literal zero for initializing and/or comparing null pointers.

== C legacy to be avoided ==

=== Use util::array instead of C-style Arrays ===

C-style arrays are very efficient, but their interface is ugly. Use <tt>util::array</tt> defined in <tt>array.hpp</tt> instead. It is a wrapper for an array which has a C++ container-style interface. If you need to, extend it to make it fit your needs.

=== Do not use C-style casts ===

The following code,

if(i->second.side() == (size_t)player_number_) {

is considered bad practice in C++ since a C-style cast is overpowered -- if types change around it could end up casting away constness, or performing an implementation-defined data reinterpretation (basically a C-style cast is a compiler-generated combination of <tt>static_cast</tt>, <tt>reinterpret_cast</tt>, and <tt>const_cast</tt>).

Good programming style is to use the least powerful tool available that does what you want. For example:

if(i->second.side() == static_cast<size_t>(player_number_)) {

Alternatively, a constructor call may be used for non-built-in types.

''Note: there may be some obscure cases where a C-style cast is desirable, such as converting a pointer to an integer type of unspecified size.''

=== Do not use #define for constants ===

<tt><nowiki>#</nowiki>define foo X</tt> is not a typesafe approach to define constants. Instead, you can something like the following (in an anonymous namespace) to achieve the same goal in a typesafe fashion.

namespace {
const T foo = X;
}

== Documentation ==

=== Document config preconditions and postconditions ===

In the Wesnoth code you will commonly encounter a data container type known as <tt>config</tt>, which contains hierarchical string data (such as WML contents or game settings). The tagged ''children'' of the <tt>config</tt> object and their string ''attributes'' are arranged in an ordered and mapped format, internally implemented using the C++ STL.

Because <tt>config</tt> data is utilized in so many ways and places, it can be difficult to track across the scope of the entire program. Thus, you should document all public functions that take/return <tt>config</tt> objects, specifying content expectations and updating any related entries in the [[ReferenceWML]] wiki pages. In particular, if your function requires a <tt>config</tt> parameter, specify where/how the <tt>config</tt> object should be created. This will be a great help to any future coders who need to call or modify your function.

=== Doxygen ===

See [[Doxygen]] for tips on how to comment the code, so that Doxygen can nicely document it.

== See also ==

* [[HackingWesnoth]]

[[Category:Development]]

SoC Information for Google

2014-02-08T18:47:18Z

SkeletonCrew: /* Description* */ Updated the information regarding the latest development release

{{Template:SoC2014}}

== SoC Information for Google ==
This is the information that we submit to google as Application in Summer of Code (current status: 2014). The submitter automatically becomes primary Admin. Most entries are mandatory and have to be filled out before the application can be submitted.

=== First page of questions ===

==== Organization id* ====
wesnoth

==== Organization Name* ====
Battle for Wesnoth

==== Description* ====
<code type="html">
Battle for Wesnoth, or simply Wesnoth, is a Free, turn-based strategy game with a high-fantasy theme that was designed in June 2003 by David White (Sirp).
Although the core rules are fairly simple and meant to be easily learned[1], they provide interesting gameplay and rich tactical options. A major strength of the project is the Wesnoth Markup Language (WML) for writing scenarios. Programming skills are not required to compose with it, and a large WML-modding community has generated a vast amount of user-maintained content. We polish the best of this content and lift it into our official release tree.
The first stable release (1.0) was on October 2, 2005, and the latest stable release (1.10.7) happened in August 2013. Version 1.10 was released in January 2012, while the current development branch is at version 1.11.9, released at the beginning of February 2014. We are currently working towards another stable release which should be out in Q2 2014.
Wesnoth is one of the most successful open-source game projects in existence, with an exceptionally large developer base and user community:
<ul>
<li>We support two multiplayer game servers (stable and development) with a usual minimum load of more than a hundred players</li>
<li>More than a thousand downloads a day</li>
<li>more than 6 million downloads via SourceForge; many more via various mirrors of Linux distributions</li>
<li>Game of the year 2007, 2008, 2009, 2010, 2011 and 2012 at LinuxQuestions.org[2][3]</li>
<li>In general, Wesnoth tends to show up in the first or second position whenever anyone compiles a list of top open-source games</li>
</ul>
Wesnoth's most notable features include:
<ul>
<li>A mature project with continuing active development and frequent improvements after 10 years of development</li>
<li>High quality artwork: both original graphics and music</li>
<li>Well-balanced by a tireless team of playtesters</li>
<li>Fun, unique gameplay</li>
<li>Even after a decade of development and a very solid, fun product already created, there are still plenty of new developers</li>
<li>Strong support of internationalization with many supported languages, thus experience in working with non-native English speakers. In fact, more than half of our developers are not native English speakers.</li>
</ul>
For our Ideas page, please have a look at [4]. There you can find all information required to get you started working on Wesnoth.
[1] http://www.wesnoth.org/wiki/WesnothPhilosophy 
[2] http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/ 
[3] http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/ 
[4] http://wiki.wesnoth.org/SummerOfCodeIdeas
</code>

==== Tags ====
ai_development, ai, artificial_intelligence, lua, multiplayer, game_development, c++, game_engine, game, games, graphics, server, scripting, extensibility

==== Main license* ====
GNU General Public License version 2.0 (GPLv2) [Dropdown box answer!]

==== Logo URL ====
https://raw.github.com/wesnoth/wesnoth-old/master/icons/wesnoth-icon.png

==== Ideas list* ====
http://wiki.wesnoth.org/SummerOfCodeIdeas

==== Mailing list ====
wesnoth-dev@gna.org

==== Organization website* ====
http://www.wesnoth.org/

==== IRC Channel ====
#wesnoth-dev on irc.freenode.net

==== Feed URL ====
[left empty]

==== Google+ URL ====
[left empty]

==== Twitter URL ====
[left empty]

==== Blog page ====
[left empty]

==== Facebook URL ====
[left empty]

==== Backup administrator* ====
neuhausercova

==== Checkboxes ====
===== Veteran organization =====
Checked

===== I hereby declare that the applying organization is not located in any of the countries which are not eligible to participate in the program: Iran, Syria, Cuba, Sudan, North Korea and Myanmar (Burma).* =====
Checked

=== Second page of questions ===

==== Why is your organization applying to participate in Google Summer of Code 2014? What do you hope to gain by participating?* ====
Most of our developers have particular areas of interest in which they work. Though they are efficient in their areas, there are other, presently uncovered, areas of the code with a need for improvements but a high barrier to entry for casual contributors. By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart work in these areas and others that are lagging behind. Our previous SoC experience shows that a motivated, full-time, student can be brought up to date in any area fairly quickly. Our previous experiences has shown us that SoC developers tend to stay after the end of the Summer of Code and become valuable members of our community. Finally, we feel that it is part of our mandate is to provide a platform for motivated contributors to develop their skills in a positive learning environment.

Overall GSOC has been a win for all parties and we want it to continue in the future.

==== How many potential mentors do you have for this year's program? What criteria did you use to select them?* ====
This year 5 developers stepped up stating they would be willing to mentor. Not all of them will be able to handle a student singlehandedly, but applying some cooperation concepts we will make sure that our students never feel left alone.

Our first criterion for mentor selection was that all the people had to be volunteers. According to other open source projects and our experience from the last six years, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.

AI has been a long term contributor and developer who now wants to take responsibility for a student. He is one of our resident lua experts and also handles several tasks reaching over into automated testing and building.

Iurii Chernyi (Crab) has joined the team in 2009, taking part in Google Summer of Code 2009, and staying with the project as a developer after successful completion of GSoC. He's an expert on all aspects of current Wesnoth AI codebase (having fully reorganized it as part of GSoC 2009), and has fixed numerous bugs all over Wesnoth. He was a GSoC mentor 2010, 2011 and 2012. In 2011 he was a GCI mentor and administrator. He is experienced in teaching other people, in areas like programming languages and math.

Mordante is one of the most active developers on our IRC channel. Not only has he done preliminary studies and coding in multiple areas that are candidates for Summer of Code ideas, he also is one of the coders with the best overview of the Wesnoth code. A large part of his work involves refactoring and polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base. He is currently completing a rewrite of the Wesnoth GUI library, making all windows configurable through WML. This should make it easier to use Wesnoth on different resolutions, from small handheld devices to large 30 inch screens. Mordante has been a GSoC mentor for Wesnoth since 2008.

Thunderstruck was a student in GSoC 2013 and stayed around to improve the game. During our regular meeting at FOSDEM he stated that he will try to find time during the summer to help students work on the games backend. Based on his GSoC contribution he has become an expert in our engines internal workings reducing the differences between singleplayer and multiplayer content.

Trademark is another of our GSoC 2013 students who intends to stay an active developer. He wants to push the development of our Add-On server to the next level introducing new concepts and ideas. One of these ideas is the move to C++11 and using some highly specialized libs to create a sound basis for one of the highlights Wesnoth features, the easy availability of user created content.

All other developers listed in the ideas page are the leading capacities we do have for the respecting areas. Have a look at our list of "people who to contact" [1] for an easy reference. In general all our developers will mentor all students. That is, questions should just be asked in our IRC channel, where basically every developer who has an idea can and will directly answer.

When choosing the mentors, we have kept in mind that most developers can answer most technical questions, and we have chosen people that are well known for interacting with new-comers/external developers and can provide general guidance and design advice, more than people with specific technical knowledge.

[3] http://wiki.wesnoth.org/SoC_People_to_bug_on_IRC

==== What is your plan for dealing with disappearing students?* ====
The first thing to do is to avoid this situation altogether. The key is identifying candidates with the right mix of skills and temperament. Wesnoth is a game, and as such has lots of developers that are not coders. In particular, artists are well known in the Wesnoth community for being very sensitive about criticism and our community is used to people being sensitive to critics.

We try to choose students that accept criticism and are able to filter constructive criticism from useless one. The Wesnoth developer community is used to judging people according to these criteria and the special title we are going to give to applicants will allow us to easily spot any such problems and discuss them before they grow out of control.

If a student disappears, their mentor are in charge of reconnecting the student to see what is going wrong (available time, tension with other developers, with members of the community etc...). Depending on the actual problem, the mentor and the student will have to agree on possible ways to resolve the problem.

If a student disappears completely and there is no way to get back to them, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have repository write access, so most of the work will be committed either to trunk or to a specific branch) and find a core developer to take on the job. This will probably be slower and less effective for the project, but it's the best we can do.

==== What is your plan for dealing with disappearing mentors?* ====
Most of our mentors are long time developers that volunteered for the job, so we don't expect that to happen. We observed in during the last years the amount of time required to mentor, and our mentors accepted the job knowing the amount of work it involved. Most of this years mentors mentored last year as well, most have contributed since 2008, or been organizational admins.

However, should it happen, we would continue to mentor as a developer community the student until we find a new "official" mentor to take on the job.

==== What steps will you take to encourage students to interact with your project's community before and during the program?* ====
Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two (non trival) patches... you're in". With other words, anybody that is able to get two non-trivial patches applied is offered commit privileges.
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our EasyCoding pages [1] (these projects are usually a couple of hours long and hve been chosen to provide easy access to the respective area of code). This year, we also have added some simple coding tasks directly related to our GSoC ideas to be able to test students more specifically on their future project

Usually, patches go back and forth a couple of times, to make sure that all secondary things are in place (indenting, coding style, modified buildfiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to keep our project alive.

If the student is proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

In previous years, all students that were accepted (and a couple more) managed to have commit access before the start of the coding phase. We consider that this policy was successful and we plan to keep it this year.

We also plan to give a special forum title to any students. This will allow all forum members to tell them apart from normal users and give them read/write access to the developer only forums. This will also allow us to quickly spot any problem they might have interacting with the player community. We have a very mature developer community, but our player community is made of all sort of people of all age and education, and it can sometimes be rough.

Last, our experience from previous years is that students that participate in the community during the evaluation period will stay active in the community after that period. In previous years this has been a discriminating criterias for students of similar level, and overall we never had problems of students working "behind a black wall." Our selection process tend to favor students who participate, and participation hasn't been a problem so far.

[1] http://wiki.wesnoth.org/EasyCoding

==== What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes?* ====
The steps meant to involve the students in the community are the same steps we use to make it easy and rewarding to stay with the community even after Summer of Code is over. We really try to make students feel part of the community, particularly as equal developers, rather than just students working a summer job. This, we think, make them feel empowered, and want to remain an important part of the community.

==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====
[left empty]

==== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ====
[left empty]

==== If you chose "veteran" in the organization profile dropdown, please summarize your involvement and the successes and challenges of your participation. Please also list your pass/fail rate for each year. ====
Since 2008 we have participated in 5 years of GSOC, with good results. With the exception of our first year, we pass approximately 75% of our students, and usually get some really interesting code from them.

2008 results:
Wesnoth participated in GSoC 2008 with four students. Out of these, two were great successes (that is they became full-fledge developers before the actual start of GSoC), did huge improvement during GSoC (A new recruitment algorithm for the AI and the basic structure for a new map editor, the student finished this work after the summer), and are still active developers in the Wesnoth community, even after 5 years. Two others eventually failed, but we learned from them that while great students should be left on their own, average students should be monitored much more closely than we did. If things seems to start to go wrong, it's important to react very quick, to meet with other mentors and get things back on track early.

Timezone problems were also a serious barrier for student/mentor communication, and we will take that more into account when pairing mentors and students.

For our other students, multiple problems collectively led to failure:
* We should enforce IRC communication, E-mail is a barrier. This applies both for students and mentors. Both should be on IRC several hours a day, with overlapping hours.
* We should be more strict about mid-term evaluation. If the student is slightly lacking at mid-term we should give a clear message that he needs to get back on track.

2009 results:
In 2009 we mentored 6 students as part of Summer of Code. Out of these 5 projects were a success. From those 5 developers 3 are still part of our core development group and still maintain and improve the work they submitted as part of Summer of Code. One of the students even became the "head" of our AI development department and mentored a student this year. For a summary of the 2009 results have a look at [1].

2010 results:
In 2010 we mentored 4 students as part of Summer of Code, all the projects were a success. from those 4 developers, 1 is still part of our code development team and maintains the work he has done as part of Summer of Code.

2011 results:
In 2011 we mentored 5 students, with four of those successfully completed their projects. Some continued the work polishing their projects a little further even after GSoC, one continues to actively polish his work and just released a new version of his WML Editor.

2012 results:
In 2012 we mentored five students with four of them completing their project successfully. Most were from a set list of ideas provided by the project, which were aimed at fixing or updating parts of the code that never seemed to get fixed.

2013 results:
In 2013 we mentored three students, all of them completing their project successfully. The projects centered around unification of singleplayer and multiplayer content, work on recreating the add-on server as well as improvements for our AI to ensure units are recruited smartly.

[1] http://forums.wesnoth.org/viewtopic.php?f=5&t=26955

2008: 2/4
2009: 5/6
2010: 4/4
2011: 4/5
2012: 4/5
2013: 3/3

==== If you are a new organization, have you applied in the past? If so, for what year(s)? ====
[left empty]

==== Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? ====
[left empty]

=== Old questions and answers ===

== Application template ==
This template is no longer asked for during the initial application. Listing it here so that we can still reference it later on.

==== Does your organization have an application template you would like to see students use? ====

Students wishing to participate in GSoC should copy the questions below to a new page and fill it with the answers.

Please note that we generally plan to meet potential students through our IRC channel. So beside just answering these questions, potential candidates consider visiting us in IRC: #wesnoth-dev on irc.freenode.net. This is where most of our work takes place and participating in IRC is mandatory for GSoC students participating with Wesnoth. Our experience is that this is the easiest way to communicate and solve problems that come up.

1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

1.4) Why do you want to participate in summer of code?

1.5) What are you studying, subject, level and school?

1.6) What country are you from, at what time are you most likely to be able to join IRC?

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

2) Experience

2.1) What programs/software have you worked on before?

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or gameplay?

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

3.2) What spoken languages are you fluent in?

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

3.6) Are you good at sorting useful criticisms from useless ones?

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

4.2) If you have invented your own project, please describe the project and the scope.

4.3) Why did you choose this project?

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

4.5) Include as much technical detail about your implementation as you can

4.6) What do you expect to gain from this project?

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
* Git (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* Python (optional, mainly used for tools)
* build environments (eg cmake/scons)
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)

5.2) Which tools do you normally use for development? Why do you use them?

5.3) What programming languages are you fluent in?

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

In general, students should be as verbose as possible in their answers and feel free to elaborate.

SoC Information for Google

2014-02-08T18:16:37Z

SkeletonCrew: /* Description* */ Make the links look sane

{{Template:SoC2014}}

== SoC Information for Google ==
This is the information that we submit to google as Application in Summer of Code (current status: 2014). The submitter automatically becomes primary Admin. Most entries are mandatory and have to be filled out before the application can be submitted.

=== First page of questions ===

==== Organization id* ====
wesnoth

==== Organization Name* ====
Battle for Wesnoth

==== Description* ====
<code type="html">
Battle for Wesnoth, or simply Wesnoth, is a Free, turn-based strategy game with a high-fantasy theme that was designed in June 2003 by David White (Sirp).
Although the core rules are fairly simple and meant to be easily learned[1], they provide interesting gameplay and rich tactical options. A major strength of the project is the Wesnoth Markup Language (WML) for writing scenarios. Programming skills are not required to compose with it, and a large WML-modding community has generated a vast amount of user-maintained content. We polish the best of this content and lift it into our official release tree.
The first stable release (1.0) was on October 2, 2005, and the latest stable release (1.10.7) happened in August 2013. Version 1.10 was released in January 2012, while the current development branch is at version 1.11.8, released at the beginning of January 2014. We are currently working towards another stable release which should be out in Q2 2014.
Wesnoth is one of the most successful open-source game projects in existence, with an exceptionally large developer base and user community:
<ul>
<li>We support two multiplayer game servers (stable and development) with a usual minimum load of more than a hundred players</li>
<li>More than a thousand downloads a day</li>
<li>more than 6 million downloads via SourceForge; many more via various mirrors of Linux distributions</li>
<li>Game of the year 2007, 2008, 2009, 2010, 2011 and 2012 at LinuxQuestions.org[2][3]</li>
<li>In general, Wesnoth tends to show up in the first or second position whenever anyone compiles a list of top open-source games</li>
</ul>
Wesnoth's most notable features include:
<ul>
<li>A mature project with continuing active development and frequent improvements after 10 years of development</li>
<li>High quality artwork: both original graphics and music</li>
<li>Well-balanced by a tireless team of playtesters</li>
<li>Fun, unique gameplay</li>
<li>Even after a decade of development and a very solid, fun product already created, there are still plenty of new developers</li>
<li>Strong support of internationalization with many supported languages, thus experience in working with non-native English speakers. In fact, more than half of our developers are not native English speakers.</li>
</ul>
For our Ideas page, please have a look at [4]. There you can find all information required to get you started working on Wesnoth.
[1] http://www.wesnoth.org/wiki/WesnothPhilosophy 
[2] http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/ 
[3] http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/ 
[4] http://wiki.wesnoth.org/SummerOfCodeIdeas
</code>

==== Tags ====
ai_development, ai, artificial_intelligence, lua, multiplayer, game_development, c++, game_engine, game, games, graphics, server, scripting, extensibility

==== Main license* ====
GNU General Public License version 2.0 (GPLv2) [Dropdown box answer!]

==== Logo URL ====
https://raw.github.com/wesnoth/wesnoth-old/master/icons/wesnoth-icon.png

==== Ideas list* ====
http://wiki.wesnoth.org/SummerOfCodeIdeas

==== Mailing list ====
wesnoth-dev@gna.org

==== Organization website* ====
http://www.wesnoth.org/

==== IRC Channel ====
#wesnoth-dev on irc.freenode.net

==== Feed URL ====
[left empty]

==== Google+ URL ====
[left empty]

==== Twitter URL ====
[left empty]

==== Blog page ====
[left empty]

==== Facebook URL ====
[left empty]

==== Backup administrator* ====
neuhausercova

==== Checkboxes ====
===== Veteran organization =====
Checked

===== I hereby declare that the applying organization is not located in any of the countries which are not eligible to participate in the program: Iran, Syria, Cuba, Sudan, North Korea and Myanmar (Burma).* =====
Checked

=== Second page of questions ===

==== Why is your organization applying to participate in Google Summer of Code 2014? What do you hope to gain by participating?* ====
Most of our developers have particular areas of interest in which they work. Though they are efficient in their areas, there are other, presently uncovered, areas of the code with a need for improvements but a high barrier to entry for casual contributors. By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart work in these areas and others that are lagging behind. Our previous SoC experience shows that a motivated, full-time, student can be brought up to date in any area fairly quickly. Our previous experiences has shown us that SoC developers tend to stay after the end of the Summer of Code and become valuable members of our community. Finally, we feel that it is part of our mandate is to provide a platform for motivated contributors to develop their skills in a positive learning environment.

Overall GSOC has been a win for all parties and we want it to continue in the future.

==== How many potential mentors do you have for this year's program? What criteria did you use to select them?* ====
This year 5 developers stepped up stating they would be willing to mentor. Not all of them will be able to handle a student singlehandedly, but applying some cooperation concepts we will make sure that our students never feel left alone.

Our first criterion for mentor selection was that all the people had to be volunteers. According to other open source projects and our experience from the last six years, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.

AI has been a long term contributor and developer who now wants to take responsibility for a student. He is one of our resident lua experts and also handles several tasks reaching over into automated testing and building.

Iurii Chernyi (Crab) has joined the team in 2009, taking part in Google Summer of Code 2009, and staying with the project as a developer after successful completion of GSoC. He's an expert on all aspects of current Wesnoth AI codebase (having fully reorganized it as part of GSoC 2009), and has fixed numerous bugs all over Wesnoth. He was a GSoC mentor 2010, 2011 and 2012. In 2011 he was a GCI mentor and administrator. He is experienced in teaching other people, in areas like programming languages and math.

Mordante is one of the most active developers on our IRC channel. Not only has he done preliminary studies and coding in multiple areas that are candidates for Summer of Code ideas, he also is one of the coders with the best overview of the Wesnoth code. A large part of his work involves refactoring and polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base. He is currently completing a rewrite of the Wesnoth GUI library, making all windows configurable through WML. This should make it easier to use Wesnoth on different resolutions, from small handheld devices to large 30 inch screens. Mordante has been a GSoC mentor for Wesnoth since 2008.

Thunderstruck was a student in GSoC 2013 and stayed around to improve the game. During our regular meeting at FOSDEM he stated that he will try to find time during the summer to help students work on the games backend. Based on his GSoC contribution he has become an expert in our engines internal workings reducing the differences between singleplayer and multiplayer content.

Trademark is another of our GSoC 2013 students who intends to stay an active developer. He wants to push the development of our Add-On server to the next level introducing new concepts and ideas. One of these ideas is the move to C++11 and using some highly specialized libs to create a sound basis for one of the highlights Wesnoth features, the easy availability of user created content.

All other developers listed in the ideas page are the leading capacities we do have for the respecting areas. Have a look at our list of "people who to contact" [1] for an easy reference. In general all our developers will mentor all students. That is, questions should just be asked in our IRC channel, where basically every developer who has an idea can and will directly answer.

When choosing the mentors, we have kept in mind that most developers can answer most technical questions, and we have chosen people that are well known for interacting with new-comers/external developers and can provide general guidance and design advice, more than people with specific technical knowledge.

[3] http://wiki.wesnoth.org/SoC_People_to_bug_on_IRC

==== What is your plan for dealing with disappearing students?* ====
The first thing to do is to avoid this situation altogether. The key is identifying candidates with the right mix of skills and temperament. Wesnoth is a game, and as such has lots of developers that are not coders. In particular, artists are well known in the Wesnoth community for being very sensitive about criticism and our community is used to people being sensitive to critics.

We try to choose students that accept criticism and are able to filter constructive criticism from useless one. The Wesnoth developer community is used to judging people according to these criteria and the special title we are going to give to applicants will allow us to easily spot any such problems and discuss them before they grow out of control.

If a student disappears, their mentor are in charge of reconnecting the student to see what is going wrong (available time, tension with other developers, with members of the community etc...). Depending on the actual problem, the mentor and the student will have to agree on possible ways to resolve the problem.

If a student disappears completely and there is no way to get back to them, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have repository write access, so most of the work will be committed either to trunk or to a specific branch) and find a core developer to take on the job. This will probably be slower and less effective for the project, but it's the best we can do.

==== What is your plan for dealing with disappearing mentors?* ====
Most of our mentors are long time developers that volunteered for the job, so we don't expect that to happen. We observed in during the last years the amount of time required to mentor, and our mentors accepted the job knowing the amount of work it involved. Most of this years mentors mentored last year as well, most have contributed since 2008, or been organizational admins.

However, should it happen, we would continue to mentor as a developer community the student until we find a new "official" mentor to take on the job.

==== What steps will you take to encourage students to interact with your project's community before and during the program?* ====
Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two (non trival) patches... you're in". With other words, anybody that is able to get two non-trivial patches applied is offered commit privileges.
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our EasyCoding pages [1] (these projects are usually a couple of hours long and hve been chosen to provide easy access to the respective area of code). This year, we also have added some simple coding tasks directly related to our GSoC ideas to be able to test students more specifically on their future project

Usually, patches go back and forth a couple of times, to make sure that all secondary things are in place (indenting, coding style, modified buildfiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to keep our project alive.

If the student is proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

In previous years, all students that were accepted (and a couple more) managed to have commit access before the start of the coding phase. We consider that this policy was successful and we plan to keep it this year.

We also plan to give a special forum title to any students. This will allow all forum members to tell them apart from normal users and give them read/write access to the developer only forums. This will also allow us to quickly spot any problem they might have interacting with the player community. We have a very mature developer community, but our player community is made of all sort of people of all age and education, and it can sometimes be rough.

Last, our experience from previous years is that students that participate in the community during the evaluation period will stay active in the community after that period. In previous years this has been a discriminating criterias for students of similar level, and overall we never had problems of students working "behind a black wall." Our selection process tend to favor students who participate, and participation hasn't been a problem so far.

[1] http://wiki.wesnoth.org/EasyCoding

==== What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes?* ====
The steps meant to involve the students in the community are the same steps we use to make it easy and rewarding to stay with the community even after Summer of Code is over. We really try to make students feel part of the community, particularly as equal developers, rather than just students working a summer job. This, we think, make them feel empowered, and want to remain an important part of the community.

==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====
[left empty]

==== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ====
[left empty]

==== If you chose "veteran" in the organization profile dropdown, please summarize your involvement and the successes and challenges of your participation. Please also list your pass/fail rate for each year. ====
Since 2008 we have participated in 5 years of GSOC, with good results. With the exception of our first year, we pass approximately 75% of our students, and usually get some really interesting code from them.

2008 results:
Wesnoth participated in GSoC 2008 with four students. Out of these, two were great successes (that is they became full-fledge developers before the actual start of GSoC), did huge improvement during GSoC (A new recruitment algorithm for the AI and the basic structure for a new map editor, the student finished this work after the summer), and are still active developers in the Wesnoth community, even after 5 years. Two others eventually failed, but we learned from them that while great students should be left on their own, average students should be monitored much more closely than we did. If things seems to start to go wrong, it's important to react very quick, to meet with other mentors and get things back on track early.

Timezone problems were also a serious barrier for student/mentor communication, and we will take that more into account when pairing mentors and students.

For our other students, multiple problems collectively led to failure:
* We should enforce IRC communication, E-mail is a barrier. This applies both for students and mentors. Both should be on IRC several hours a day, with overlapping hours.
* We should be more strict about mid-term evaluation. If the student is slightly lacking at mid-term we should give a clear message that he needs to get back on track.

2009 results:
In 2009 we mentored 6 students as part of Summer of Code. Out of these 5 projects were a success. From those 5 developers 3 are still part of our core development group and still maintain and improve the work they submitted as part of Summer of Code. One of the students even became the "head" of our AI development department and mentored a student this year. For a summary of the 2009 results have a look at [1].

2010 results:
In 2010 we mentored 4 students as part of Summer of Code, all the projects were a success. from those 4 developers, 1 is still part of our code development team and maintains the work he has done as part of Summer of Code.

2011 results:
In 2011 we mentored 5 students, with four of those successfully completed their projects. Some continued the work polishing their projects a little further even after GSoC, one continues to actively polish his work and just released a new version of his WML Editor.

2012 results:
In 2012 we mentored five students with four of them completing their project successfully. Most were from a set list of ideas provided by the project, which were aimed at fixing or updating parts of the code that never seemed to get fixed.

2013 results:
In 2013 we mentored three students, all of them completing their project successfully. The projects centered around unification of singleplayer and multiplayer content, work on recreating the add-on server as well as improvements for our AI to ensure units are recruited smartly.

[1] http://forums.wesnoth.org/viewtopic.php?f=5&t=26955

2008: 2/4
2009: 5/6
2010: 4/4
2011: 4/5
2012: 4/5
2013: 3/3

==== If you are a new organization, have you applied in the past? If so, for what year(s)? ====
[left empty]

==== Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? ====
[left empty]

=== Old questions and answers ===

== Application template ==
This template is no longer asked for during the initial application. Listing it here so that we can still reference it later on.

==== Does your organization have an application template you would like to see students use? ====

Students wishing to participate in GSoC should copy the questions below to a new page and fill it with the answers.

Please note that we generally plan to meet potential students through our IRC channel. So beside just answering these questions, potential candidates consider visiting us in IRC: #wesnoth-dev on irc.freenode.net. This is where most of our work takes place and participating in IRC is mandatory for GSoC students participating with Wesnoth. Our experience is that this is the easiest way to communicate and solve problems that come up.

1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

1.4) Why do you want to participate in summer of code?

1.5) What are you studying, subject, level and school?

1.6) What country are you from, at what time are you most likely to be able to join IRC?

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

2) Experience

2.1) What programs/software have you worked on before?

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or gameplay?

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

3.2) What spoken languages are you fluent in?

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

3.6) Are you good at sorting useful criticisms from useless ones?

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

4.2) If you have invented your own project, please describe the project and the scope.

4.3) Why did you choose this project?

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

4.5) Include as much technical detail about your implementation as you can

4.6) What do you expect to gain from this project?

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
* Git (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* Python (optional, mainly used for tools)
* build environments (eg cmake/scons)
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)

5.2) Which tools do you normally use for development? Why do you use them?

5.3) What programming languages are you fluent in?

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

In general, students should be as verbose as possible in their answers and feel free to elaborate.

SoC Information for Google

2014-02-08T18:08:41Z

SkeletonCrew: /* What is your plan for dealing with disappearing mentors?* */ not all mentors have mentored before

{{Template:SoC2014}}

== SoC Information for Google ==
This is the information that we submit to google as Application in Summer of Code (current status: 2014). The submitter automatically becomes primary Admin. Most entries are mandatory and have to be filled out before the application can be submitted.

=== First page of questions ===

==== Organization id* ====
wesnoth

==== Organization Name* ====
Battle for Wesnoth

==== Description* ====
<code type="html">
Battle for Wesnoth, or simply Wesnoth, is a Free, turn-based strategy game with a high-fantasy theme that was designed in June 2003 by David White (Sirp).
Although the core rules are fairly simple and meant to be easily learned[1], they provide interesting gameplay and rich tactical options. A major strength of the project is the Wesnoth Markup Language (WML) for writing scenarios. Programming skills are not required to compose with it, and a large WML-modding community has generated a vast amount of user-maintained content. We polish the best of this content and lift it into our official release tree.
The first stable release (1.0) was on October 2, 2005, and the latest stable release (1.10.7) happened in August 2013. Version 1.10 was released in January 2012, while the current development branch is at version 1.11.8, released at the beginning of January 2014. We are currently working towards another stable release which should be out in Q2 2014.
Wesnoth is one of the most successful open-source game projects in existence, with an exceptionally large developer base and user community:
<ul>
<li>We support two multiplayer game servers (stable and development) with a usual minimum load of more than a hundred players</li>
<li>More than a thousand downloads a day</li>
<li>more than 6 million downloads via SourceForge; many more via various mirrors of Linux distributions</li>
<li>Game of the year 2007, 2008, 2009, 2010, 2011 and 2012 at LinuxQuestions.org[2][3]</li>
<li>In general, Wesnoth tends to show up in the first or second position whenever anyone compiles a list of top open-source games</li>
</ul>
Wesnoth's most notable features include:
<ul>
<li>A mature project with continuing active development and frequent improvements after 10 years of development</li>
<li>High quality artwork: both original graphics and music</li>
<li>Well-balanced by a tireless team of playtesters</li>
<li>Fun, unique gameplay</li>
<li>Even after a decade of development and a very solid, fun product already created, there are still plenty of new developers</li>
<li>Strong support of internationalization with many supported languages, thus experience in working with non-native English speakers. In fact, more than half of our developers are not native English speakers.</li>
</ul>
For our Ideas page, please have a look at [4]. There you can find all information required to get you started working on Wesnoth.
[1] <a href="http://www.wesnoth.org/wiki/WesnothPhilosophy">http://www.wesnoth.org/wiki/WesnothPhilosophy</a> 
[2] <a href="http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/">http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/</a> 
[3] <a href="http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/">http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/</a> 
[4] <a href="http://wiki.wesnoth.org/SummerOfCodeIdeas">http://wiki.wesnoth.org/SummerOfCodeIdeas</a>
</code>

==== Tags ====
ai_development, ai, artificial_intelligence, lua, multiplayer, game_development, c++, game_engine, game, games, graphics, server, scripting, extensibility

==== Main license* ====
GNU General Public License version 2.0 (GPLv2) [Dropdown box answer!]

==== Logo URL ====
https://raw.github.com/wesnoth/wesnoth-old/master/icons/wesnoth-icon.png

==== Ideas list* ====
http://wiki.wesnoth.org/SummerOfCodeIdeas

==== Mailing list ====
wesnoth-dev@gna.org

==== Organization website* ====
http://www.wesnoth.org/

==== IRC Channel ====
#wesnoth-dev on irc.freenode.net

==== Feed URL ====
[left empty]

==== Google+ URL ====
[left empty]

==== Twitter URL ====
[left empty]

==== Blog page ====
[left empty]

==== Facebook URL ====
[left empty]

==== Backup administrator* ====
neuhausercova

==== Checkboxes ====
===== Veteran organization =====
Checked

===== I hereby declare that the applying organization is not located in any of the countries which are not eligible to participate in the program: Iran, Syria, Cuba, Sudan, North Korea and Myanmar (Burma).* =====
Checked

=== Second page of questions ===

==== Why is your organization applying to participate in Google Summer of Code 2014? What do you hope to gain by participating?* ====
Most of our developers have particular areas of interest in which they work. Though they are efficient in their areas, there are other, presently uncovered, areas of the code with a need for improvements but a high barrier to entry for casual contributors. By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart work in these areas and others that are lagging behind. Our previous SoC experience shows that a motivated, full-time, student can be brought up to date in any area fairly quickly. Our previous experiences has shown us that SoC developers tend to stay after the end of the Summer of Code and become valuable members of our community. Finally, we feel that it is part of our mandate is to provide a platform for motivated contributors to develop their skills in a positive learning environment.

Overall GSOC has been a win for all parties and we want it to continue in the future.

==== How many potential mentors do you have for this year's program? What criteria did you use to select them?* ====
This year 5 developers stepped up stating they would be willing to mentor. Not all of them will be able to handle a student singlehandedly, but applying some cooperation concepts we will make sure that our students never feel left alone.

Our first criterion for mentor selection was that all the people had to be volunteers. According to other open source projects and our experience from the last six years, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.

AI has been a long term contributor and developer who now wants to take responsibility for a student. He is one of our resident lua experts and also handles several tasks reaching over into automated testing and building.

Iurii Chernyi (Crab) has joined the team in 2009, taking part in Google Summer of Code 2009, and staying with the project as a developer after successful completion of GSoC. He's an expert on all aspects of current Wesnoth AI codebase (having fully reorganized it as part of GSoC 2009), and has fixed numerous bugs all over Wesnoth. He was a GSoC mentor 2010, 2011 and 2012. In 2011 he was a GCI mentor and administrator. He is experienced in teaching other people, in areas like programming languages and math.

Mordante is one of the most active developers on our IRC channel. Not only has he done preliminary studies and coding in multiple areas that are candidates for Summer of Code ideas, he also is one of the coders with the best overview of the Wesnoth code. A large part of his work involves refactoring and polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base. He is currently completing a rewrite of the Wesnoth GUI library, making all windows configurable through WML. This should make it easier to use Wesnoth on different resolutions, from small handheld devices to large 30 inch screens. Mordante has been a GSoC mentor for Wesnoth since 2008.

Thunderstruck was a student in GSoC 2013 and stayed around to improve the game. During our regular meeting at FOSDEM he stated that he will try to find time during the summer to help students work on the games backend. Based on his GSoC contribution he has become an expert in our engines internal workings reducing the differences between singleplayer and multiplayer content.

Trademark is another of our GSoC 2013 students who intends to stay an active developer. He wants to push the development of our Add-On server to the next level introducing new concepts and ideas. One of these ideas is the move to C++11 and using some highly specialized libs to create a sound basis for one of the highlights Wesnoth features, the easy availability of user created content.

All other developers listed in the ideas page are the leading capacities we do have for the respecting areas. Have a look at our list of "people who to contact" [1] for an easy reference. In general all our developers will mentor all students. That is, questions should just be asked in our IRC channel, where basically every developer who has an idea can and will directly answer.

When choosing the mentors, we have kept in mind that most developers can answer most technical questions, and we have chosen people that are well known for interacting with new-comers/external developers and can provide general guidance and design advice, more than people with specific technical knowledge.

[3] http://wiki.wesnoth.org/SoC_People_to_bug_on_IRC

==== What is your plan for dealing with disappearing students?* ====
The first thing to do is to avoid this situation altogether. The key is identifying candidates with the right mix of skills and temperament. Wesnoth is a game, and as such has lots of developers that are not coders. In particular, artists are well known in the Wesnoth community for being very sensitive about criticism and our community is used to people being sensitive to critics.

We try to choose students that accept criticism and are able to filter constructive criticism from useless one. The Wesnoth developer community is used to judging people according to these criteria and the special title we are going to give to applicants will allow us to easily spot any such problems and discuss them before they grow out of control.

If a student disappears, their mentor are in charge of reconnecting the student to see what is going wrong (available time, tension with other developers, with members of the community etc...). Depending on the actual problem, the mentor and the student will have to agree on possible ways to resolve the problem.

If a student disappears completely and there is no way to get back to them, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have repository write access, so most of the work will be committed either to trunk or to a specific branch) and find a core developer to take on the job. This will probably be slower and less effective for the project, but it's the best we can do.

==== What is your plan for dealing with disappearing mentors?* ====
Most of our mentors are long time developers that volunteered for the job, so we don't expect that to happen. We observed in during the last years the amount of time required to mentor, and our mentors accepted the job knowing the amount of work it involved. Most of this years mentors mentored last year as well, most have contributed since 2008, or been organizational admins.

However, should it happen, we would continue to mentor as a developer community the student until we find a new "official" mentor to take on the job.

==== What steps will you take to encourage students to interact with your project's community before and during the program?* ====
Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two (non trival) patches... you're in". With other words, anybody that is able to get two non-trivial patches applied is offered commit privileges.
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our EasyCoding pages [1] (these projects are usually a couple of hours long and hve been chosen to provide easy access to the respective area of code). This year, we also have added some simple coding tasks directly related to our GSoC ideas to be able to test students more specifically on their future project

Usually, patches go back and forth a couple of times, to make sure that all secondary things are in place (indenting, coding style, modified buildfiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to keep our project alive.

If the student is proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

In previous years, all students that were accepted (and a couple more) managed to have commit access before the start of the coding phase. We consider that this policy was successful and we plan to keep it this year.

We also plan to give a special forum title to any students. This will allow all forum members to tell them apart from normal users and give them read/write access to the developer only forums. This will also allow us to quickly spot any problem they might have interacting with the player community. We have a very mature developer community, but our player community is made of all sort of people of all age and education, and it can sometimes be rough.

Last, our experience from previous years is that students that participate in the community during the evaluation period will stay active in the community after that period. In previous years this has been a discriminating criterias for students of similar level, and overall we never had problems of students working "behind a black wall." Our selection process tend to favor students who participate, and participation hasn't been a problem so far.

[1] http://wiki.wesnoth.org/EasyCoding

==== What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes?* ====
The steps meant to involve the students in the community are the same steps we use to make it easy and rewarding to stay with the community even after Summer of Code is over. We really try to make students feel part of the community, particularly as equal developers, rather than just students working a summer job. This, we think, make them feel empowered, and want to remain an important part of the community.

==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====
[left empty]

==== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ====
[left empty]

==== If you chose "veteran" in the organization profile dropdown, please summarize your involvement and the successes and challenges of your participation. Please also list your pass/fail rate for each year. ====
Since 2008 we have participated in 5 years of GSOC, with good results. With the exception of our first year, we pass approximately 75% of our students, and usually get some really interesting code from them.

2008 results:
Wesnoth participated in GSoC 2008 with four students. Out of these, two were great successes (that is they became full-fledge developers before the actual start of GSoC), did huge improvement during GSoC (A new recruitment algorithm for the AI and the basic structure for a new map editor, the student finished this work after the summer), and are still active developers in the Wesnoth community, even after 5 years. Two others eventually failed, but we learned from them that while great students should be left on their own, average students should be monitored much more closely than we did. If things seems to start to go wrong, it's important to react very quick, to meet with other mentors and get things back on track early.

Timezone problems were also a serious barrier for student/mentor communication, and we will take that more into account when pairing mentors and students.

For our other students, multiple problems collectively led to failure:
* We should enforce IRC communication, E-mail is a barrier. This applies both for students and mentors. Both should be on IRC several hours a day, with overlapping hours.
* We should be more strict about mid-term evaluation. If the student is slightly lacking at mid-term we should give a clear message that he needs to get back on track.

2009 results:
In 2009 we mentored 6 students as part of Summer of Code. Out of these 5 projects were a success. From those 5 developers 3 are still part of our core development group and still maintain and improve the work they submitted as part of Summer of Code. One of the students even became the "head" of our AI development department and mentored a student this year. For a summary of the 2009 results have a look at [1].

2010 results:
In 2010 we mentored 4 students as part of Summer of Code, all the projects were a success. from those 4 developers, 1 is still part of our code development team and maintains the work he has done as part of Summer of Code.

2011 results:
In 2011 we mentored 5 students, with four of those successfully completed their projects. Some continued the work polishing their projects a little further even after GSoC, one continues to actively polish his work and just released a new version of his WML Editor.

2012 results:
In 2012 we mentored five students with four of them completing their project successfully. Most were from a set list of ideas provided by the project, which were aimed at fixing or updating parts of the code that never seemed to get fixed.

2013 results:
In 2013 we mentored three students, all of them completing their project successfully. The projects centered around unification of singleplayer and multiplayer content, work on recreating the add-on server as well as improvements for our AI to ensure units are recruited smartly.

[1] http://forums.wesnoth.org/viewtopic.php?f=5&t=26955

2008: 2/4
2009: 5/6
2010: 4/4
2011: 4/5
2012: 4/5
2013: 3/3

==== If you are a new organization, have you applied in the past? If so, for what year(s)? ====
[left empty]

==== Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? ====
[left empty]

=== Old questions and answers ===

== Application template ==
This template is no longer asked for during the initial application. Listing it here so that we can still reference it later on.

==== Does your organization have an application template you would like to see students use? ====

Students wishing to participate in GSoC should copy the questions below to a new page and fill it with the answers.

Please note that we generally plan to meet potential students through our IRC channel. So beside just answering these questions, potential candidates consider visiting us in IRC: #wesnoth-dev on irc.freenode.net. This is where most of our work takes place and participating in IRC is mandatory for GSoC students participating with Wesnoth. Our experience is that this is the easiest way to communicate and solve problems that come up.

1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

1.4) Why do you want to participate in summer of code?

1.5) What are you studying, subject, level and school?

1.6) What country are you from, at what time are you most likely to be able to join IRC?

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

2) Experience

2.1) What programs/software have you worked on before?

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or gameplay?

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

3.2) What spoken languages are you fluent in?

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

3.6) Are you good at sorting useful criticisms from useless ones?

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

4.2) If you have invented your own project, please describe the project and the scope.

4.3) Why did you choose this project?

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

4.5) Include as much technical detail about your implementation as you can

4.6) What do you expect to gain from this project?

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
* Git (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* Python (optional, mainly used for tools)
* build environments (eg cmake/scons)
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)

5.2) Which tools do you normally use for development? Why do you use them?

5.3) What programming languages are you fluent in?

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

In general, students should be as verbose as possible in their answers and feel free to elaborate.

SoC Ideas Addon Server 2013

2013-04-02T19:33:06Z

SkeletonCrew: Created the page

{{SoC2013Idea}}

=Description=
<h2>Addon Server: Create a new and shiny one</h2>
Page for the idea: [[SoC_Ideas_Addon_Server_2013]]

Wesnoth has an addon server that originally only hosted extra campaigns, but
now also hosts Multiplayer Maps, Factions, Eras and more. Also the amount of
hosted addon has increased over the years. The server itself is almost unchanged
and can use an upgrade. Performance-wise things are not bad, but it would be
nice to store additional meta-information on the server and have a better
integration for translations.

{{#dpl:
|resultsheader=''There are %PAGES% submitted student proposals for this idea''
|oneresultheader=''There is 1 submitted student proposal for this idea''
|suppresserrors=true
|noresultsheader=''There are no submitted student proposals for this idea''
|category=Summer of Code 2013 Student Page&SoC Ideas IDEA NAME
|notcategory=SoC 2013 Not Submitted To Google
|include=#Description
|nottitlematch=SoC2013_Template_of_Student_page
|mode=userformat
|format=,, See [[%PAGE%|%TITLE%]] for more information. ,
}}

=Additional Information=

The first step for this project will be writing the specifications for the new
server and discuss them with our developers and users. Once the specifications
are done you will implement the server and update the in-game user interface.

Suggested skills: C++, the boost asio library (can be learned during the process).

=Whom to ask about this=
mordante

DirectActionsWML

2013-02-09T20:33:00Z

SkeletonCrew: /* [terrain] */ Clarify the effect on villages.

{{WML Tags}}
== Direct actions ==

Direct actions are actions that have a direct effect on gameplay. They can be used inside of [[EventWML|events]].

The following tags are actions:

=== [endlevel] ===
Ends the scenario.
* '''result''': before the scenario is over, all events with ''name=result'' are triggered. If ''result=victory'', the player progresses to the next level; if ''result=defeat'', the game returns to the main menu.

When the result is "victory" the following keys can be used:
* '''bonus''': whether the player should get bonus gold (maximum possible gold that could have been earned by waiting the level out). The default is bonus=yes.
* '''carryover_report''': whether the player should receive a summary of the scenario outcome, the default is carryover_report=yes.
* '''save''': whether a start-of-scenario save should be created for the next scenario, the default is save=yes. Do not confuse this with saving of replays for the current scenario.
* '''replay_save''': whether a replay save for the current scenario is allowed, the default is replay_save=yes. If yes, the player's settings in preferences will be used to determine if a replay is saved. If no, will override and not save a replay.
* '''linger_mode''': If ...=yes, the screen is greyed out and there's the possibility to save before advancing to the next scenario, the default is linger_mode=yes.
* '''reveal_map''': (Multiplayer only) (Default is 'yes') If 'no', shroud doesn't disappear when game ended.
* '''next_scenario''': (default specified in '''[scenario]''' tag) the ID of the next scenario that should be played. All units that side 1 controls at this point become available for recall in ''next_scenario''.
* '''carryover_percentage''': by default 80% of the gold is carried over to the next scenario, with this key the amount can be changed.
* '''carryover_add''': if true the gold will be added to the starting gold the next scenario, if false the next scenario will start with the amount of the current scenario (after taxes) or the minimum in the next scenario. Default is false.
* '''music''': (default specified in '''[scenario]''' or '''[game_config]''' tags) a comma-separated list of music tracks from which one will be chosen and played once after any events related to the end of level result are executed; by default, victory_music is used on victory, and defeat_music on defeat.
* '''end_credits''': {{DevFeature1.11}} Whether to display the credits screen at the end of a single-player campaign. Defaults to ''yes''. Note that this has cumulative effects over the campaign - it persists even if the endlevel does not trigger the end of the campaign. See also [[CampaignWML]].
* '''end_text''': (translatable) Text that is shown centered in a black screen at the end of a campaign. Defaults to "The End". Note that this has cumulative effects over the campaign - it persists even if the endlevel does not trigger the end of the campaign. See also [[CampaignWML]].
* '''end_text_duration''': Delay, in milliseconds, before displaying the game credits at the end of a campaign. In other words, for how much time '''end_text''' is displayed on screen. Defaults to 3500. Note that this has cumulative effects over the campaign - it persists even if the endlevel does not trigger the end of the campaign. See also [[CampaignWML]].

=== [unit] ===
Places a unit on the map. For syntax see [[SingleUnitWML]].
* {{Short Note:Predefined Macro|GENERIC_UNIT}}
* '''to_variable''': spawn directly into a variable instead of on the map.

=== [recall] ===
Recalls a unit. The unit is recalled free of charge, and is placed near the leader.
* [[StandardUnitFilter]]: the first matching unit will be recalled. If no units match this tag is ignored. Do not use a [filter] tag. If a comma separated list is given, every unit currently considered for recall is checked against all the types (not each single one of the types against all units).
* '''x,y''': the unit is placed here instead of next to the leader.
* '''show''': yes/no, default yes: whether the unit is animated (faded in) or instantly displayed
* '''fire_event''': boolean yes|no (default no); whether any according prerecall or recall events shall be fired.
* '''check_passability''': (boolean yes|no, default yes): If yes, checks for terrain passability when placing the unit (a nearby passable hex is chosen).

=== [teleport] ===
Teleports a unit on map. {{Short Note:Predefined Macro|TELEPORT_UNIT}}
* '''[filter]''': [[StandardUnitFilter]] the first unit matching this filter will be teleported.
* '''x,y''': the position to teleport to.
* '''clear_shroud''': should shroud be cleared on arrival
* '''animate''': should a teleport animation be played (if the unit doesn't have a teleport animation, it will fade out/fade in)
* '''check_passability''': (boolean yes|no, default yes): normally, units will not be teleported into terrain that is impassable for them. Setting this attribute to "no" permits it.

(Note: There is also a ability named teleport, see [[AbilitiesWML]].)

=== [terrain_mask] ===
Changes the terrain on the map. See [[TerrainMaskWML]].

=== [terrain] ===
Changes the terrain on the map.
* '''terrain''': the character of the terrain to use. See [[TerrainCodesWML]] to see what letter a type of terrain uses.
* [[StandardLocationFilter]]. This [[StandardLocationFilter]]'s terrain= key is used for the new terrain, filtering by terrain can be done with a nested [[StandardLocationFilter]]: [and]terrain=terrain_string_to_be_filtered_for.
* '''layer''': (overlay|base|both, default=both) only change the specified layer.
* '''replace_if_failed''': (default=no) When replacing just one layer failed, try to replace the whole terrain. If '''terrain''' is an overlay only terrain, use the default_base as base layer. If the terrain has no default base, do nothing.
Note: When a hex changes from a village terrain to a non-village terrain, and a team owned that village it loses that village. When a hex changes from a non-village terrain to a village terrain and there is a unit on that hex it does not automatically capture the village. The reason for not capturing villages it that there are too many choices to make; should a unit loose its movement points, should capture events be fired. It is easier to do this as wanted by the author in WML.

=== [gold] ===
Gives sides gold.
* '''amount''': the amount of gold to give.
* '''side''': (default=1) the number of the side to give the gold to. Can be a comma-separated list of sides. note: Default side=1 for empty side= is deprecated.
* [[StandardSideFilter]] {{DevFeature1.11}} tags and keys; default for empty side= is all sides, as usual in a SSF.
* '''[filter_side]''' with a [[StandardSideFilter]] as argument {{DevFeature1.11}}: [gold][filter_side] is deprecated, use the new inline SSF.

=== [unstore_unit] ===
Creates a unit from a game variable, and activates it on the playing field. This must be a specific variable describing a unit, and may not be an array -- to unstore an entire array, iterate over it. The variable is not cleared. See also [[InternalActionsWML#.5Bstore_unit.5D|[store_unit]]], [[ConditionalActionsWML#.5Bwhile.5D|[while]]] and [[InternalActionsWML#.5Bclear_variable.5D|[clear_variable]]].
* '''variable''': the name of the variable.
* '''find_vacant''': whether the unit should be placed on the nearest vacant tile to its specified location. If this is set to 'no'(default), then any unit on the same tile as the unit being unstored will be destroyed.
* '''check_passability''': (boolean yes|no, default yes): If yes, checks for terrain passability when placing the unit. This key has no effect if find_vacant=no (no check performed then). Before 1.9 this key is always "no".
* '''text''': (translatable) floating text to display above the unit, such as a damage amount
* '''red''', '''green''', '''blue''': (default=0,0,0) the color to display the text in. Values vary from 0-255. You may find it convenient to use the {COLOR_HARM} or {COLOR_HEAL} macro instead. (Use {COLOR_HARM} or {COLOR_HEAL} instead of the whole red,green,blue= line.)
* '''advance''': (default=true) if true the unit is advanced if it has enough XP. When modifying XP make sure to do it from inside a [[EventWML#Multiplayer_safety|synchronized event]] or it may lead to OOS errors especially when several advancement paths exist. Note that advance and post advance events are called, so infinite loops can happen.
* '''fire_event''': (boolean yes|no, default no) Whether any advance/post advance events shall be fired if an advancement takes place, no effect otherwise.
* '''animate''': {{DevFeature1.11}} (boolean yes|no, default yes) Whether "levelout" and "levelin" (or fade to white and back) animations shall be played if an advancement takes place, no effect otherwise.
* '''x''' ,'''y''': override unit location, "x,y=recall,recall" will put the unit on the unit's side's recall list.
Units can be unstored with negative (or zero) hit points. This can be useful if modifying a unit in its last_breath event (as the unit's death is already the next step), but tends to look wrong in other cases. In particular, it is possible to have units with negative hit points in play. Such units are aberrations, subject to unusual behavior as the game compensates for them. (For example, such units are currently automatically hit–and killed–in combat.) The details of the unusual behavior are subject to change between stable releases without warning.

=== [allow_recruit] ===
Allows a side to recruit units it couldn't previously recruit.
* '''type''': the types of units that the side can now recruit.
* '''side''': (default=1) the number of the side that is being allowed to recruit the units. This can be a comma-separated list note: Default side=1 for empty side= is deprecated.
* [[StandardSideFilter]] {{DevFeature1.11}} tags and keys; default for empty side= is all sides, as usual in a SSF.

=== [allow_extra_recruit] ===
Allows a leader to recruit units it couldn't previously recruit.
These types add to the types the leader can recruit because of [side]recruit=.
* '''extra_recruit''': the types of units that the unit can now recruit.
* '''[[StandardUnitFilter]]''': All units matching this filter are modified. Does not match on recall list units.

=== [disallow_recruit] ===
Prevents a side from recruiting units it could previously recruit.
* '''type''': the types of units that the side can no longer recruit.
* '''side''': (default=1) the number of the side that may no longer recruit the units. This can be a comma-separated list note: Default side=1 for empty side= is deprecated.
* [[StandardSideFilter]] {{DevFeature1.11}} tags and keys; default for empty side= is all sides, as usual in a SSF.

=== [disallow_extra_recruit] ===
Prevents a leader from recruiting units it could previously recruit.
* '''extra_recruit''': the types of units that the side can no longer recruit.
* '''[[StandardUnitFilter]]''': All units matching this filter are modified. Does not match on recall list units.

=== [set_recruit] ===
Sets the units a side can recruit.
* '''recruit''': the types of units that the side can now recruit.
* '''side''': (default=1) the number of the side that is having its recruitment set. This can be a comma-separated list. note: Default side=1 for empty side= is deprecated.
* [[StandardSideFilter]] {{DevFeature1.11}} tags and keys; default for empty side= is all sides, as usual in a SSF.

=== [set_extra_recruit] ===
Sets the units a leader can recruit.
* '''extra_recruit''': the types of units that the leader can now recruit.
* '''[[StandardUnitFilter]]''': All units matching this filter are modified. Does not match on recall list units.

=== [modify_side] ===
Modifies some details of a given side in the middle of a scenario. '''The following listed properties are the only properties that [modify_side] can affect!'''
* '''side''': (default=1) the number of the side that is to be changed. note: Default side=1 for empty side= is deprecated.
* '''[filter_side]''' with a [[StandardSideFilter]] as argument
* '''income''': the income given at the begining of each turn.
* '''recruit''': a list of unit types, replacing the side's current recruitment list.
* '''team_name''': the team in which the side plays the scenario.
* '''user_team_name''': a translatable string representing the team's description. This has no effect on alliances. Defaults to ''team_name''.
* '''gold''': the amount of gold the side owns.
* '''village_gold''': the income setting per village for the side.
* '''controller''': the identifier string of the side's controller. Uses the same syntax of the ''controller'' key in the [[SideWML|[side]]] tag.
* '''fog''': a boolean string (yes/no) describing the status of Fog for the side.
* '''shroud''': a boolean string describing the status of Shroud for the side.
* '''hidden''': a boolean string specifying whether side is shown in status table.
* '''color''': {{DevFeature1.11}} a team color range specification, name (e.g. "red", "blue"), or number (e.g. "1", "2") for this side. The default color range names, numbers, and definitions can be found in data/core/team_colors.cfg.
* '''[ai]''': replaces a side's AI parameters with the new specified ones. Uses the same syntax described in [[AiWML]].
* '''switch_ai''': replaces a side ai with a new AI from specified file(ignoring those AI parameters above). Path to file follows the usual WML convention.
* '''reset_maps''': {{DevFeature1.11}} If set to "yes", then the shroud is spread to all hexes, covering the parts of the map that had already been explored by the side, including hexes currently seen. (Seen hexes will be cleared at the end of most events; they can also be manually cleared with {{tag|InterfaceActionsWML|redraw}}.) This is only effective if shroud is on, but this is evaluated after shroud= (and before shroud_data=).
* '''reset_view''': {{DevFeature1.11}} If set to "yes", then the fog of war is spread to all hexes, covering the parts of the map that had already been seen this turn by the side, including hexes currently seen, excluding hexes affected by multi-turn {{tag|DirectActionsWML|lift_fog}}. (Seen hexes will be cleared at the end of most events; they can also be manually cleared with {{tag|InterfaceActionsWML|redraw}}.) This is only effective if fog is on, but this is evaluated after fog=.
* '''share_maps''': change the share_maps side attribute. Be sure to use shroud=yes for that side and have it as an ally
* '''share_view''': change the share_view side attribute. Be sure to use fog=yes for that side and have it as an ally
* '''shroud_data''': changes to the side's shroud, using the same format as when defining the [side].
* '''suppress_end_turn_confirmation''': {{DevFeature1.11}} Boolean value controlling whether or not a player is asked for confirmation when skipping a turn.

=== [modify_turns] ===
Modifies the turn limit in the middle of a scenario.
* '''value''': the new turn limit.
* '''add''': if used instead of ''value'', specifies the number of turns to add to the current limit (can be negative).
* '''current''': changes the current turn number after applying turn limit modifications, if any. It is not possible to change the turn number to exceed the turn limit (1 <= current turns <= max turns).

=== [allow_end_turn] ===
Allows human players to end their turn through the user interface if they were previously affected by the '''[disallow_end_turn]''' action. This action doesn't take any arguments.

=== [disallow_end_turn] ===
Disallows human players to end their turn through the user interface. This action doesn't take any arguments.

=== [capture_village] ===
Changes the ownership of a village.
* [[StandardLocationFilter]]: all village locations matching the filter are affected.
* '''side''': the side that takes control of the village. This side needs to have a leader (canrecruit=yes). If the side key is not given, the village will become neutral (unless [filter_side] is present, in which case that side fiter decides, see below).
* '''[filter_side]''' with [[StandardSideFilter]] tags and keys as arguments; if both this tag and inline side= are present it's an error. Otherwise, the first matching side gets ownership (or the village becomes neutral if none match).
* '''fire_event''' (boolean yes|no, default: no): Whether any capture events shall be fired.

=== [kill] ===
Removes all units (including units in a recall list) that match the filter from the game.
* [[StandardUnitFilter]]: Selection criterion; do not use a [filter] tag.
* '''animate''': if 'yes', displays the unit dying (fading away).
* '''fire_event''': if 'yes', triggers any appropriate 'die' events (See [[EventWML]]). Note that events are only fired for killed units that have been on the map (as opposed to recall list).
* '''[secondary_unit]''' with a [[StandardUnitFilter]] as argument. Do not use a [filter] tag. Has an effect only if fire_event=yes. The first on-map unit matching the filter becomes second_unit in any fired die and last breath events. If an on-map unit matches and if there are several units killed with a single [kill] tag, second_unit is this same unit for all of them. If no on-map unit matches or [secondary_unit] isn't present, the variable second_unit in each of the die and last breath events is always the same as the variable unit (the dying unit).

=== [move_unit] ===
works like the MOVE_UNIT macro.
* [[StandardUnitFilter]] as argument; do not use a [filter] tag. All units matching the filter are moved. If the target location is occupied, the nearest free location is chosen.
* '''to_x''' (unsigned integer): The units are moved to this x coordinate. Can be a comma-separated list, in which case the unit follows this given path during the move.
* '''to_y''' (unsigned integer): The units are moved to this y coordinate. Can be a comma-separated list.
* '''fire_event''' (optional, boolean yes|no, default no): Whether any according moveto events shall be fired. The target location ($x1, $y1 in the event) may not be the same location that the unit was tried to be moved to, if the original target location is occupied or impassable.
* '''check_passability''' (boolean yes|no, default yes): Whether the terrain the unit is moved to should be checked for suiting the unit. (If it does not, a nearby suitable hex is chosen.)

=== [modify_ai] ===
Changes AI objects (aspects, goals, candidate actions or stages) for a specified side. See [[AiWML#Adding_and_Deleting_Aspects_with_the_.5Bmodify_ai.5D_Tag|AiWML]] for full description.

* '''action''' (string): Takes values 'add', 'change', 'delete' or 'try_delete' to do just that for the AI object.
* '''path''' (string): Describes which AI object is to be modified.
* '''[facet]''', '''[goal]''', '''[candidate_action]''' or '''[stage]''': Details about the AI object to be modified.
* [[StandardSideFilter]] {{DevFeature1.11}} tags and keys; default for empty side= is all sides, as usual in a SSF.
* '''[filter_side]''' with a [[StandardSideFilter]] as argument {{DevFeature1.11}}: [modify_ai][filter_side] is deprecated, use the new inline SSF.

=== [modify_unit] ===
works similar to the MODIFY_UNIT macro.
* '''[filter]''' with a [[StandardUnitFilter]] as argument. All units matching this filter are modified. Matches on recall list units too.
* Accepts generally the syntax inside of wml unit variables created by [store_unit] which can be viewed in a savefile or by using the :inspect command. Can add traits with immediate effect. Cannot remove things. Subtags with the same name must be written in the correct order to match them with the tag they are supposed to modify.
example usage (see also the test scenario):
[modify_unit]
[filter]
x,y=38,6
[/filter]
hitpoints=10
{TRAIT_HEALTHY}
[/modify_unit]

The unit which is currently modified is accessible via $this_unit, e.g. hitpoints = "$($this_unit.hitpoints / 2)" to set the hitpoints of all units to half of their particular maxima. This this_unit variable is independent from the this_unit variable available in the SUF used to determine which units to modify (first all matching units are gathered, and then all those are modified).

note: The syntax allowed is somehow vague. Just try things and possibly correct/add/modify this documentation. (a [http://forums.wesnoth.org/viewtopic.php?f=21&t=31676& forum thread] discusses some related issues).

=== [transform_unit] ===
Transforms every unit matching the filter to the given unit type. Keeps intact hit points, experience and status. If the unit is transformed to a non-living type (undead or mechanical), it will be also unpoisoned.
{{DevFeature1.11}} Hit points will be changed if necessary to respect the transformed unit's maximum hit points.
* [[StandardUnitFilter]]: do not use a [filter] tag.
* '''transform_to''': the unit type in which all the units matching the filter will be transformed. If missing, the units will follow their normal advancement.

=== [petrify] ===

* [[StandardUnitFilter]] as an argument. Do not use a [filter] tag. All units matching this filter are petrified. Recall list units are included.

=== [unpetrify] ===
* [[StandardUnitFilter]] as an argument. Do not use a [filter] tag. All units matching this filter are unpetrified. Recall list units are included.

=== [object] ===
Gives some unit an object which modifies their stats in some way.
* '''id''': (Optional) when the object is picked up, a flag is set for ''id''. The object cannot be picked up if a flag for ''id'' has been set. This means that any object with an id can only be used once, even if first_time_only=no is set for the event. This restriction is per level. In a campaign objects with the same id can be assigned once per level.
* '''delayed_variable_substitution''' (boolean yes|no, default no): If set to "yes", the wml block contained in this [object] is not variable-substituted at execution time of the event where this [object] is within. You need this to work around a bug when adding ABILITY_TELEPORT via an [object] or when using [object][effect][filter]with a $this_unit (see http://gna.org/bugs/index.php?18893).
* '''[effect]''': one or more effect elements may be listed. See [[EffectWML]] for a description of [effect].
* '''duration''':
**if 'level', effects only last until the end of the level (note : 'level' is the scenario, so this doesn't mean it last until the unit levels-up). {{DevFeature1.11}} 'level' has been renamed to 'scenario'.
**if 'forever' or not set, effects never wear off.
** {{DevFeature1.11}} if 'turn', effects only last until the start of the unit's next turn (when the unit refreshes movement and attacks). (Like other start-of-turn behavior, objects with a duration of "turn" won't expire before turn 2.)
* '''[filter]''' with a [[StandardUnitFilter]] as argument. The first unit found that matches the filter will be given the object. Only on-map units are considered. If no unit matches or no [filter] is supplied, it is tried to apply the object to the unit at the $x1,$y1 location of the event where this [object] is in. The case of no unit being at that spot is handled in the same way as no unit matching a given filter ([else] commands executed, cannot_use_message displayed)
* '''[then]''': a subtag that lets you execute actions if the filter conditions are met. The most common action that should be inside here is a '''[remove_item]''' tag, but you could probably put any tags that otherwise work in a [then] tag.
* '''[else]''': a subtag that lets you execute actions if the filter conditions are *not* met.
* '''silent''': whether or not messages should be suppressed. Default is "no".
* '''image''': the displayed image of the object.
* '''name''': (translatable) displayed as a caption of the image.

* '''description''': (translatable) displayed as a message of the image.
* '''cannot_use_message''': (translatable) displayed instead of '''description''' if no unit passes the filter test.

=== [remove_shroud] ===
Removes some shroud from the map for a certain side (only relevant for sides that have shroud=yes).
* '''side''': (default=1) the side for which to remove shroud. This can be a comma-separated list of sides. note: Default side=1 for empty side= is deprecated.
* '''[filter_side]''' with a [[StandardSideFilter]] as argument
* [[StandardLocationFilter]]: the range of tiles for which shroud should be removed

=== [place_shroud] ===
Places some shroud on the map for a certain side (only relevant for sides that have shroud=yes).
* '''side''': (default=1) the side for which to place shroud. This can be a comma-separated list. note: Default side=1 for empty side= is deprecated.
* '''[filter_side]''' with a [[StandardSideFilter]] as argument
* [[StandardLocationFilter]]: the range of tiles on which shroud should be placed

=== [lift_fog] ===
{{DevFeature1.11}}Lifts the fog of war from parts of the map for a certain side (only relevant for sides that have fog=yes), allowing a player to witness what occurs there even if that player has no units within vision range.
* '''[filter_side]''' with a [[StandardSideFilter]] indicating which sides should be affected.
* [[StandardLocationFilter]]: the tiles from which fog should be lifted.
* '''multiturn''': ''yes/no, default:no''. The default (not multiturn) causes fog to be removed in the same way that normal vision works; the cleared tiles will remain cleared until fog is recalculated (which normally happens when a side ends its turn). When multiturn is set to "yes", the cleared tiles remain clear until {{tag||reset_fog}} cancels the clearing. This allows tiles to remain clear for multiple turns, or to be refogged before the end of the current turn (without also refogging all tiles). Multiturn lifted fog is not shared with allies (even when share_view=yes).

=== [reset_fog] ===
{{DevFeature1.11}}The primary use of this tag is to remove multiturn lifted fog (created by {{tag||lift_fog}}), which causes the fog to reset to what it would have been had WML not interfered. (That is, hexes that a side's units could not see at any point this turn will be re-fogged, while seen hexes remain defogged.)
* '''[filter_side]''' with a [[StandardSideFilter]] indicating which sides should be affected.
* [[StandardLocationFilter]]: the fog reset will be restricted to these tiles.
* '''reset_view''': ''yes/no, default: no'' If set to "yes", then in addition to removing multiturn fog, the side's current view is canceled (independent of the SLF). This means that all hexes will become fogged for the side unless multiturn fog exists outside the tiles selected by the SLF. Normally, one would want the currently seen hexes to become clear of fog; this is done automatically at the end of many events, and it can be done manually with {{tag|InterfaceActionsWML|redraw}}.
Omitting both the SSF and the SLF would cancel all earlier uses of [lift_fog].
Additionally setting reset_view="yes" would cause the side's entire map to be fogged (unless an ally keeps hexes clear by sharing its view).

=== [allow_undo] ===

Normally when an event with a handler fires, the player's undo stack is cleared, preventing all actions performed so far from being undone. Including this tag in the event handler prevents the stack from being cleared for this reason, allowing the player to undo actions. (However, the stack might still be cleared for other reasons, such as fog being cleared or combat occurring.) In the common cases, this means '''[allow_undo]''' allows the current action to be undone even though an event was handled. There is a less common case, though — specifically when handling a menu item, where there is no current action — and in this case, '''[allow_undo]''' means merely that earlier actions can still be undone.
* {{DevFeature1.11}} Using this tag in a menu item has an additional side effect in 1.11. Starting with version 1.11.1, executing a WML menu item normally counts as doing something as far as the "you have not started your turn yet" dialog is concerned. However, a menu item whose handler includes '''[allow_undo]''' will not count.

This tag does nothing during recruit and recall actions, as the game incorrectly ignores whether or not an event fired during those times. {{DevFeature1.11}} This has been fixed in the latest development release.

The types of actions that can be undone are movement, recruitment, recalling, and dismissing a unit from the recall list. If an action is undone, only the position (or existence) of the involved unit will be restored; any altered variables or changes to the game will remain changed after the action is undone. It is up to the scenario designer to avoid abusing this command.
* Technically, if '''[allow_undo]''' is inside an '''[event]''' with ''first_time_only=yes'' (the default setting), and the user undoes the event, then the state of the game has changed in this way: the event will not fire a second time, even though the user undid the action the first time.

=== [heal_unit] ===
Heal a unit. The variable '''$heal_amount''' will be set to the exact number of points healed (i.e can be lesser than the parameter '''amount''' if the unit is fully healed). $heal_amount contains only the number of hitpoints the first unit that was found got healed.
* '''[filter]''': [[StandardUnitFilter]] All matching on-map units are healed. If no filter is supplied, it is tried to take the unit at $x1, $y1.
* '''[filter_second]''': [[StandardUnitFilter]] all the units matching the filter ''and'' having the ''heals'' ability will have their animation played (if ''animate'' is set to true) for each of the units healed.
* '''amount''': (integer, default full) the maximum points the unit(s) will be healed. Can't set below 1 or above max_hitpoints. If "full", sets hitpoints to max_hitpoints. Before 1.9 the default is 0.
* '''animate''': a boolean which indicate if the healing animations must be played. (default no)
* '''moves''': (integer, default 0) The maximum current movement points the units will be "healed". Can't set below 0 or above max_moves. If "full", sets moves to max_moves.
* '''restore_attacks''': (boolean, default no) Whether the units' attacks_left should be reset to their max_attacks (usually 1).
* '''restore_statuses''': (boolean, default yes) Whether standard statuses should be reset to "no". This affects poisoned, slowed, petrified and unhealable. Before 1.9 this is always "no".

=== [harm_unit] ===
Harms every unit matching the filter, for the specific damage amount.
* '''[filter]''': [[StandardUnitFilter]] all matching units will be harmed (required).
* '''[filter_second]''': [[StandardUnitFilter]] if present, the first matching unit will attack all the units matching the filter above.
* '''amount''': the amount of damage that will be done (required).
* '''alignment''': (default neutral) applies an alignment to the damage, this means that if alignment=chaotic, the damage will be increased at night and reduced at day.
* '''damage_type''': if present, amount will be altered by unit resistance to the damage type specified.
* '''kill''': (default yes) if yes, when a harmed unit goes to or below 0 HP, it is killed; if no its HP are set to 1.
* '''fire_event''': (default no) if yes, when a unit is killed by harming, the corresponding events are fired.
* '''animate''': (default no) if yes, scrolls to each unit before harming it and plays its defense (or attack, if it's the harmer) and death animations. Special values supported, other than the usual yes and no, are "attacker", that means only the harmer will be animated, and "defender", that means only the harmed units will be animated.
* '''[primary_attack], [secondary_attack]''': these set the weapon against which the harmed units will defend, and that the harming unit will use to attack, respectively (notice this is the opposite of '''[filter]''' and '''[filter_second]''' above). This allows for playing specific defense and attack animations. Both tags are expected to contain a [[FilterWML#Filtering_Weapons|Standard Weapon Filter]].
* '''delay''': if animate=yes, sets the delay (in milliseconds, default 500) between each unit harming.
* '''variable''': if present, the damage caused to the unit, altered by resistances, will be stored in a WML array with the given name, under the "harm_amount" key.
* '''poisoned, slowed, petrified, unhealable''': (default no) if yes, every harmed unit that doesn't already have such status will have it set.
* '''experience''': if yes, and there is a harmer, experience will be attributed like in regular combat.
* '''resistance_multiplier''': {{DevFeature1.11}} the harmed unit's resistance is multiplied by the supplied value; this means that a value lower than 1 increases it, and a value greater than 1 decreases it. Default value is 1, that means no modification.

=== [time_area] ===
How a day should progress in a given area. Everywhere not specified in a [time_area] tag is affected by the [time] tags in the [scenario] tag.
* [[StandardLocationFilter]]: the locations to affect. ''note: only for [event][time_area]s - at scenario toplevel [time_area] does not support [[StandardLocationFilter]], only location ranges''
* [[TimeWML]]: the new schedule.
* '''id''': an unique identifier assigned to a time_area. Optional, unless you want to remove the time_area later. Can be a comma-separated list when removing time_areas, see below.
* '''remove''': (boolean) yes/no value. Indicates whether the specified time_area should be removed. Requires an identifier. If no identifier is used, however, all time_areas are removed.

''Example:'' (caves in parts of a map)
[time_area]
x=1-2,4-5
y=1-2,1-2
{UNDERGROUND}
[/time_area]

=== [end_turn] ===
End the current side's turn. The current event is finished before the turn is ended. Also, if the current event (where the tag appears) has been fired by another event, that event (and the complete stack of other possible parent events) is ended before [end_turn] comes into affect. Also, events following the event stack that fired [end_turn] are not omitted (e.g. [end_turn] is used by a side turn event and a turn refresh event does something afterwards).

=== [replace_map] ===

Replaces the entire map.
* '''map''': Content of a wesnoth map file. example:
map="{campaigns/Heir_To_The_Throne/maps/01_The_Elves_Besieged.map}"
* '''expand''': if 'yes', allows the map size to increase. The expansion direction is currently always bottom-right.
* '''shrink''': if 'yes', allows the map size to decrease. If the map size is reduced, any units that would no longer be on the map due to its coordinates no longer existing will be put into the recall list.
Note: When a hex changes from a village terrain to a non-village terrain, and a team owned that village it loses that village. When a hex changes from a non-village terrain to a village terrain and there is a unit on that hex it does not automatically capture the village. The reason for not capturing villages it that there are too many choices to make; should a unit loose its movement points, should capture events be fired. It is easier to do this as wanted by the author in WML.

=== [replace_schedule] ===
Replace the time of day schedule of the entire scenario.
* [[TimeWML]]: the new schedule.

=== [tunnel] ===

Create a tunnel between some locations, later usable by units to move from source hex to target hex (using the movement cost of unit on the target terrain). ([http://forums.wesnoth.org/viewtopic.php?f=21&t=14749&p=405667&hilit=tunnel#p405667 source])

* '''id''' identifier for the tunnel, to allow removing (optional).
* '''remove''': (boolean) yes/no value. If yes, removes all defined tunnels with the same ID (then only id= is necessary). (default: no)
* '''bidirectional''': (boolean) if yes, creates also a tunnel in the other direction. (default: yes)
* '''always_visible''': (boolean) if yes, the possible movement of enemies under fog can be seen. (default: no)
* '''[source]''': [[StandardLocationFilter]] the source hex(es) (required).
* '''[target]''': [[StandardLocationFilter]] the target hex(es) (required).
* '''[filter]''': [[StandardUnitFilter]] the units which can use the tunnel (required). Leave empty for "all units".

(Note: The tunnel tag can also be used inside the [[AbilitiesWML|[teleport]]] ability, without remove= and id=).

== Useful Macros ==
There are some predefined macros that you find useful for direct actions. You can find a complete list along with a detailed explanation of how they work [http://www.wesnoth.org/macro-reference.xhtml here].
* '''{MOVE_UNIT}''': Moves a unit to another location in the map and the player sees the movement (unlike [teleport])
* '''{FULL_HEAL}''': Brings a unit to full HP
* '''{LOYAL_UNIT}''': Create a loyal unit
* '''{MODIFY_TERRAIN_MASK}''': Modify an area of terrain

== See Also ==

* [[InternalActionsWML]]
* [[InterfaceActionsWML]]
* [[EventWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]
[[Category: ActionsWML]]

DirectActionsWML

2013-02-09T20:32:55Z

SkeletonCrew: /* [replace_map] */ Clarify the effect on villages.

{{WML Tags}}
== Direct actions ==

Direct actions are actions that have a direct effect on gameplay. They can be used inside of [[EventWML|events]].

The following tags are actions:

=== [endlevel] ===
Ends the scenario.
* '''result''': before the scenario is over, all events with ''name=result'' are triggered. If ''result=victory'', the player progresses to the next level; if ''result=defeat'', the game returns to the main menu.

When the result is "victory" the following keys can be used:
* '''bonus''': whether the player should get bonus gold (maximum possible gold that could have been earned by waiting the level out). The default is bonus=yes.
* '''carryover_report''': whether the player should receive a summary of the scenario outcome, the default is carryover_report=yes.
* '''save''': whether a start-of-scenario save should be created for the next scenario, the default is save=yes. Do not confuse this with saving of replays for the current scenario.
* '''replay_save''': whether a replay save for the current scenario is allowed, the default is replay_save=yes. If yes, the player's settings in preferences will be used to determine if a replay is saved. If no, will override and not save a replay.
* '''linger_mode''': If ...=yes, the screen is greyed out and there's the possibility to save before advancing to the next scenario, the default is linger_mode=yes.
* '''reveal_map''': (Multiplayer only) (Default is 'yes') If 'no', shroud doesn't disappear when game ended.
* '''next_scenario''': (default specified in '''[scenario]''' tag) the ID of the next scenario that should be played. All units that side 1 controls at this point become available for recall in ''next_scenario''.
* '''carryover_percentage''': by default 80% of the gold is carried over to the next scenario, with this key the amount can be changed.
* '''carryover_add''': if true the gold will be added to the starting gold the next scenario, if false the next scenario will start with the amount of the current scenario (after taxes) or the minimum in the next scenario. Default is false.
* '''music''': (default specified in '''[scenario]''' or '''[game_config]''' tags) a comma-separated list of music tracks from which one will be chosen and played once after any events related to the end of level result are executed; by default, victory_music is used on victory, and defeat_music on defeat.
* '''end_credits''': {{DevFeature1.11}} Whether to display the credits screen at the end of a single-player campaign. Defaults to ''yes''. Note that this has cumulative effects over the campaign - it persists even if the endlevel does not trigger the end of the campaign. See also [[CampaignWML]].
* '''end_text''': (translatable) Text that is shown centered in a black screen at the end of a campaign. Defaults to "The End". Note that this has cumulative effects over the campaign - it persists even if the endlevel does not trigger the end of the campaign. See also [[CampaignWML]].
* '''end_text_duration''': Delay, in milliseconds, before displaying the game credits at the end of a campaign. In other words, for how much time '''end_text''' is displayed on screen. Defaults to 3500. Note that this has cumulative effects over the campaign - it persists even if the endlevel does not trigger the end of the campaign. See also [[CampaignWML]].

=== [unit] ===
Places a unit on the map. For syntax see [[SingleUnitWML]].
* {{Short Note:Predefined Macro|GENERIC_UNIT}}
* '''to_variable''': spawn directly into a variable instead of on the map.

=== [recall] ===
Recalls a unit. The unit is recalled free of charge, and is placed near the leader.
* [[StandardUnitFilter]]: the first matching unit will be recalled. If no units match this tag is ignored. Do not use a [filter] tag. If a comma separated list is given, every unit currently considered for recall is checked against all the types (not each single one of the types against all units).
* '''x,y''': the unit is placed here instead of next to the leader.
* '''show''': yes/no, default yes: whether the unit is animated (faded in) or instantly displayed
* '''fire_event''': boolean yes|no (default no); whether any according prerecall or recall events shall be fired.
* '''check_passability''': (boolean yes|no, default yes): If yes, checks for terrain passability when placing the unit (a nearby passable hex is chosen).

=== [teleport] ===
Teleports a unit on map. {{Short Note:Predefined Macro|TELEPORT_UNIT}}
* '''[filter]''': [[StandardUnitFilter]] the first unit matching this filter will be teleported.
* '''x,y''': the position to teleport to.
* '''clear_shroud''': should shroud be cleared on arrival
* '''animate''': should a teleport animation be played (if the unit doesn't have a teleport animation, it will fade out/fade in)
* '''check_passability''': (boolean yes|no, default yes): normally, units will not be teleported into terrain that is impassable for them. Setting this attribute to "no" permits it.

(Note: There is also a ability named teleport, see [[AbilitiesWML]].)

=== [terrain_mask] ===
Changes the terrain on the map. See [[TerrainMaskWML]].

=== [terrain] ===
Changes the terrain on the map.
* '''terrain''': the character of the terrain to use. See [[TerrainCodesWML]] to see what letter a type of terrain uses.
* [[StandardLocationFilter]]. This [[StandardLocationFilter]]'s terrain= key is used for the new terrain, filtering by terrain can be done with a nested [[StandardLocationFilter]]: [and]terrain=terrain_string_to_be_filtered_for.
* '''layer''': (overlay|base|both, default=both) only change the specified layer.
* '''replace_if_failed''': (default=no) When replacing just one layer failed, try to replace the whole terrain. If '''terrain''' is an overlay only terrain, use the default_base as base layer. If the terrain has no default base, do nothing.

=== [gold] ===
Gives sides gold.
* '''amount''': the amount of gold to give.
* '''side''': (default=1) the number of the side to give the gold to. Can be a comma-separated list of sides. note: Default side=1 for empty side= is deprecated.
* [[StandardSideFilter]] {{DevFeature1.11}} tags and keys; default for empty side= is all sides, as usual in a SSF.
* '''[filter_side]''' with a [[StandardSideFilter]] as argument {{DevFeature1.11}}: [gold][filter_side] is deprecated, use the new inline SSF.

=== [unstore_unit] ===
Creates a unit from a game variable, and activates it on the playing field. This must be a specific variable describing a unit, and may not be an array -- to unstore an entire array, iterate over it. The variable is not cleared. See also [[InternalActionsWML#.5Bstore_unit.5D|[store_unit]]], [[ConditionalActionsWML#.5Bwhile.5D|[while]]] and [[InternalActionsWML#.5Bclear_variable.5D|[clear_variable]]].
* '''variable''': the name of the variable.
* '''find_vacant''': whether the unit should be placed on the nearest vacant tile to its specified location. If this is set to 'no'(default), then any unit on the same tile as the unit being unstored will be destroyed.
* '''check_passability''': (boolean yes|no, default yes): If yes, checks for terrain passability when placing the unit. This key has no effect if find_vacant=no (no check performed then). Before 1.9 this key is always "no".
* '''text''': (translatable) floating text to display above the unit, such as a damage amount
* '''red''', '''green''', '''blue''': (default=0,0,0) the color to display the text in. Values vary from 0-255. You may find it convenient to use the {COLOR_HARM} or {COLOR_HEAL} macro instead. (Use {COLOR_HARM} or {COLOR_HEAL} instead of the whole red,green,blue= line.)
* '''advance''': (default=true) if true the unit is advanced if it has enough XP. When modifying XP make sure to do it from inside a [[EventWML#Multiplayer_safety|synchronized event]] or it may lead to OOS errors especially when several advancement paths exist. Note that advance and post advance events are called, so infinite loops can happen.
* '''fire_event''': (boolean yes|no, default no) Whether any advance/post advance events shall be fired if an advancement takes place, no effect otherwise.
* '''animate''': {{DevFeature1.11}} (boolean yes|no, default yes) Whether "levelout" and "levelin" (or fade to white and back) animations shall be played if an advancement takes place, no effect otherwise.
* '''x''' ,'''y''': override unit location, "x,y=recall,recall" will put the unit on the unit's side's recall list.
Units can be unstored with negative (or zero) hit points. This can be useful if modifying a unit in its last_breath event (as the unit's death is already the next step), but tends to look wrong in other cases. In particular, it is possible to have units with negative hit points in play. Such units are aberrations, subject to unusual behavior as the game compensates for them. (For example, such units are currently automatically hit–and killed–in combat.) The details of the unusual behavior are subject to change between stable releases without warning.

=== [allow_recruit] ===
Allows a side to recruit units it couldn't previously recruit.
* '''type''': the types of units that the side can now recruit.
* '''side''': (default=1) the number of the side that is being allowed to recruit the units. This can be a comma-separated list note: Default side=1 for empty side= is deprecated.
* [[StandardSideFilter]] {{DevFeature1.11}} tags and keys; default for empty side= is all sides, as usual in a SSF.

=== [allow_extra_recruit] ===
Allows a leader to recruit units it couldn't previously recruit.
These types add to the types the leader can recruit because of [side]recruit=.
* '''extra_recruit''': the types of units that the unit can now recruit.
* '''[[StandardUnitFilter]]''': All units matching this filter are modified. Does not match on recall list units.

=== [disallow_recruit] ===
Prevents a side from recruiting units it could previously recruit.
* '''type''': the types of units that the side can no longer recruit.
* '''side''': (default=1) the number of the side that may no longer recruit the units. This can be a comma-separated list note: Default side=1 for empty side= is deprecated.
* [[StandardSideFilter]] {{DevFeature1.11}} tags and keys; default for empty side= is all sides, as usual in a SSF.

=== [disallow_extra_recruit] ===
Prevents a leader from recruiting units it could previously recruit.
* '''extra_recruit''': the types of units that the side can no longer recruit.
* '''[[StandardUnitFilter]]''': All units matching this filter are modified. Does not match on recall list units.

=== [set_recruit] ===
Sets the units a side can recruit.
* '''recruit''': the types of units that the side can now recruit.
* '''side''': (default=1) the number of the side that is having its recruitment set. This can be a comma-separated list. note: Default side=1 for empty side= is deprecated.
* [[StandardSideFilter]] {{DevFeature1.11}} tags and keys; default for empty side= is all sides, as usual in a SSF.

=== [set_extra_recruit] ===
Sets the units a leader can recruit.
* '''extra_recruit''': the types of units that the leader can now recruit.
* '''[[StandardUnitFilter]]''': All units matching this filter are modified. Does not match on recall list units.

=== [modify_side] ===
Modifies some details of a given side in the middle of a scenario. '''The following listed properties are the only properties that [modify_side] can affect!'''
* '''side''': (default=1) the number of the side that is to be changed. note: Default side=1 for empty side= is deprecated.
* '''[filter_side]''' with a [[StandardSideFilter]] as argument
* '''income''': the income given at the begining of each turn.
* '''recruit''': a list of unit types, replacing the side's current recruitment list.
* '''team_name''': the team in which the side plays the scenario.
* '''user_team_name''': a translatable string representing the team's description. This has no effect on alliances. Defaults to ''team_name''.
* '''gold''': the amount of gold the side owns.
* '''village_gold''': the income setting per village for the side.
* '''controller''': the identifier string of the side's controller. Uses the same syntax of the ''controller'' key in the [[SideWML|[side]]] tag.
* '''fog''': a boolean string (yes/no) describing the status of Fog for the side.
* '''shroud''': a boolean string describing the status of Shroud for the side.
* '''hidden''': a boolean string specifying whether side is shown in status table.
* '''color''': {{DevFeature1.11}} a team color range specification, name (e.g. "red", "blue"), or number (e.g. "1", "2") for this side. The default color range names, numbers, and definitions can be found in data/core/team_colors.cfg.
* '''[ai]''': replaces a side's AI parameters with the new specified ones. Uses the same syntax described in [[AiWML]].
* '''switch_ai''': replaces a side ai with a new AI from specified file(ignoring those AI parameters above). Path to file follows the usual WML convention.
* '''reset_maps''': {{DevFeature1.11}} If set to "yes", then the shroud is spread to all hexes, covering the parts of the map that had already been explored by the side, including hexes currently seen. (Seen hexes will be cleared at the end of most events; they can also be manually cleared with {{tag|InterfaceActionsWML|redraw}}.) This is only effective if shroud is on, but this is evaluated after shroud= (and before shroud_data=).
* '''reset_view''': {{DevFeature1.11}} If set to "yes", then the fog of war is spread to all hexes, covering the parts of the map that had already been seen this turn by the side, including hexes currently seen, excluding hexes affected by multi-turn {{tag|DirectActionsWML|lift_fog}}. (Seen hexes will be cleared at the end of most events; they can also be manually cleared with {{tag|InterfaceActionsWML|redraw}}.) This is only effective if fog is on, but this is evaluated after fog=.
* '''share_maps''': change the share_maps side attribute. Be sure to use shroud=yes for that side and have it as an ally
* '''share_view''': change the share_view side attribute. Be sure to use fog=yes for that side and have it as an ally
* '''shroud_data''': changes to the side's shroud, using the same format as when defining the [side].
* '''suppress_end_turn_confirmation''': {{DevFeature1.11}} Boolean value controlling whether or not a player is asked for confirmation when skipping a turn.

=== [modify_turns] ===
Modifies the turn limit in the middle of a scenario.
* '''value''': the new turn limit.
* '''add''': if used instead of ''value'', specifies the number of turns to add to the current limit (can be negative).
* '''current''': changes the current turn number after applying turn limit modifications, if any. It is not possible to change the turn number to exceed the turn limit (1 <= current turns <= max turns).

=== [allow_end_turn] ===
Allows human players to end their turn through the user interface if they were previously affected by the '''[disallow_end_turn]''' action. This action doesn't take any arguments.

=== [disallow_end_turn] ===
Disallows human players to end their turn through the user interface. This action doesn't take any arguments.

=== [capture_village] ===
Changes the ownership of a village.
* [[StandardLocationFilter]]: all village locations matching the filter are affected.
* '''side''': the side that takes control of the village. This side needs to have a leader (canrecruit=yes). If the side key is not given, the village will become neutral (unless [filter_side] is present, in which case that side fiter decides, see below).
* '''[filter_side]''' with [[StandardSideFilter]] tags and keys as arguments; if both this tag and inline side= are present it's an error. Otherwise, the first matching side gets ownership (or the village becomes neutral if none match).
* '''fire_event''' (boolean yes|no, default: no): Whether any capture events shall be fired.

=== [kill] ===
Removes all units (including units in a recall list) that match the filter from the game.
* [[StandardUnitFilter]]: Selection criterion; do not use a [filter] tag.
* '''animate''': if 'yes', displays the unit dying (fading away).
* '''fire_event''': if 'yes', triggers any appropriate 'die' events (See [[EventWML]]). Note that events are only fired for killed units that have been on the map (as opposed to recall list).
* '''[secondary_unit]''' with a [[StandardUnitFilter]] as argument. Do not use a [filter] tag. Has an effect only if fire_event=yes. The first on-map unit matching the filter becomes second_unit in any fired die and last breath events. If an on-map unit matches and if there are several units killed with a single [kill] tag, second_unit is this same unit for all of them. If no on-map unit matches or [secondary_unit] isn't present, the variable second_unit in each of the die and last breath events is always the same as the variable unit (the dying unit).

=== [move_unit] ===
works like the MOVE_UNIT macro.
* [[StandardUnitFilter]] as argument; do not use a [filter] tag. All units matching the filter are moved. If the target location is occupied, the nearest free location is chosen.
* '''to_x''' (unsigned integer): The units are moved to this x coordinate. Can be a comma-separated list, in which case the unit follows this given path during the move.
* '''to_y''' (unsigned integer): The units are moved to this y coordinate. Can be a comma-separated list.
* '''fire_event''' (optional, boolean yes|no, default no): Whether any according moveto events shall be fired. The target location ($x1, $y1 in the event) may not be the same location that the unit was tried to be moved to, if the original target location is occupied or impassable.
* '''check_passability''' (boolean yes|no, default yes): Whether the terrain the unit is moved to should be checked for suiting the unit. (If it does not, a nearby suitable hex is chosen.)

=== [modify_ai] ===
Changes AI objects (aspects, goals, candidate actions or stages) for a specified side. See [[AiWML#Adding_and_Deleting_Aspects_with_the_.5Bmodify_ai.5D_Tag|AiWML]] for full description.

* '''action''' (string): Takes values 'add', 'change', 'delete' or 'try_delete' to do just that for the AI object.
* '''path''' (string): Describes which AI object is to be modified.
* '''[facet]''', '''[goal]''', '''[candidate_action]''' or '''[stage]''': Details about the AI object to be modified.
* [[StandardSideFilter]] {{DevFeature1.11}} tags and keys; default for empty side= is all sides, as usual in a SSF.
* '''[filter_side]''' with a [[StandardSideFilter]] as argument {{DevFeature1.11}}: [modify_ai][filter_side] is deprecated, use the new inline SSF.

=== [modify_unit] ===
works similar to the MODIFY_UNIT macro.
* '''[filter]''' with a [[StandardUnitFilter]] as argument. All units matching this filter are modified. Matches on recall list units too.
* Accepts generally the syntax inside of wml unit variables created by [store_unit] which can be viewed in a savefile or by using the :inspect command. Can add traits with immediate effect. Cannot remove things. Subtags with the same name must be written in the correct order to match them with the tag they are supposed to modify.
example usage (see also the test scenario):
[modify_unit]
[filter]
x,y=38,6
[/filter]
hitpoints=10
{TRAIT_HEALTHY}
[/modify_unit]

The unit which is currently modified is accessible via $this_unit, e.g. hitpoints = "$($this_unit.hitpoints / 2)" to set the hitpoints of all units to half of their particular maxima. This this_unit variable is independent from the this_unit variable available in the SUF used to determine which units to modify (first all matching units are gathered, and then all those are modified).

note: The syntax allowed is somehow vague. Just try things and possibly correct/add/modify this documentation. (a [http://forums.wesnoth.org/viewtopic.php?f=21&t=31676& forum thread] discusses some related issues).

=== [transform_unit] ===
Transforms every unit matching the filter to the given unit type. Keeps intact hit points, experience and status. If the unit is transformed to a non-living type (undead or mechanical), it will be also unpoisoned.
{{DevFeature1.11}} Hit points will be changed if necessary to respect the transformed unit's maximum hit points.
* [[StandardUnitFilter]]: do not use a [filter] tag.
* '''transform_to''': the unit type in which all the units matching the filter will be transformed. If missing, the units will follow their normal advancement.

=== [petrify] ===

* [[StandardUnitFilter]] as an argument. Do not use a [filter] tag. All units matching this filter are petrified. Recall list units are included.

=== [unpetrify] ===
* [[StandardUnitFilter]] as an argument. Do not use a [filter] tag. All units matching this filter are unpetrified. Recall list units are included.

=== [object] ===
Gives some unit an object which modifies their stats in some way.
* '''id''': (Optional) when the object is picked up, a flag is set for ''id''. The object cannot be picked up if a flag for ''id'' has been set. This means that any object with an id can only be used once, even if first_time_only=no is set for the event. This restriction is per level. In a campaign objects with the same id can be assigned once per level.
* '''delayed_variable_substitution''' (boolean yes|no, default no): If set to "yes", the wml block contained in this [object] is not variable-substituted at execution time of the event where this [object] is within. You need this to work around a bug when adding ABILITY_TELEPORT via an [object] or when using [object][effect][filter]with a $this_unit (see http://gna.org/bugs/index.php?18893).
* '''[effect]''': one or more effect elements may be listed. See [[EffectWML]] for a description of [effect].
* '''duration''':
**if 'level', effects only last until the end of the level (note : 'level' is the scenario, so this doesn't mean it last until the unit levels-up). {{DevFeature1.11}} 'level' has been renamed to 'scenario'.
**if 'forever' or not set, effects never wear off.
** {{DevFeature1.11}} if 'turn', effects only last until the start of the unit's next turn (when the unit refreshes movement and attacks). (Like other start-of-turn behavior, objects with a duration of "turn" won't expire before turn 2.)
* '''[filter]''' with a [[StandardUnitFilter]] as argument. The first unit found that matches the filter will be given the object. Only on-map units are considered. If no unit matches or no [filter] is supplied, it is tried to apply the object to the unit at the $x1,$y1 location of the event where this [object] is in. The case of no unit being at that spot is handled in the same way as no unit matching a given filter ([else] commands executed, cannot_use_message displayed)
* '''[then]''': a subtag that lets you execute actions if the filter conditions are met. The most common action that should be inside here is a '''[remove_item]''' tag, but you could probably put any tags that otherwise work in a [then] tag.
* '''[else]''': a subtag that lets you execute actions if the filter conditions are *not* met.
* '''silent''': whether or not messages should be suppressed. Default is "no".
* '''image''': the displayed image of the object.
* '''name''': (translatable) displayed as a caption of the image.

* '''description''': (translatable) displayed as a message of the image.
* '''cannot_use_message''': (translatable) displayed instead of '''description''' if no unit passes the filter test.

=== [remove_shroud] ===
Removes some shroud from the map for a certain side (only relevant for sides that have shroud=yes).
* '''side''': (default=1) the side for which to remove shroud. This can be a comma-separated list of sides. note: Default side=1 for empty side= is deprecated.
* '''[filter_side]''' with a [[StandardSideFilter]] as argument
* [[StandardLocationFilter]]: the range of tiles for which shroud should be removed

=== [place_shroud] ===
Places some shroud on the map for a certain side (only relevant for sides that have shroud=yes).
* '''side''': (default=1) the side for which to place shroud. This can be a comma-separated list. note: Default side=1 for empty side= is deprecated.
* '''[filter_side]''' with a [[StandardSideFilter]] as argument
* [[StandardLocationFilter]]: the range of tiles on which shroud should be placed

=== [lift_fog] ===
{{DevFeature1.11}}Lifts the fog of war from parts of the map for a certain side (only relevant for sides that have fog=yes), allowing a player to witness what occurs there even if that player has no units within vision range.
* '''[filter_side]''' with a [[StandardSideFilter]] indicating which sides should be affected.
* [[StandardLocationFilter]]: the tiles from which fog should be lifted.
* '''multiturn''': ''yes/no, default:no''. The default (not multiturn) causes fog to be removed in the same way that normal vision works; the cleared tiles will remain cleared until fog is recalculated (which normally happens when a side ends its turn). When multiturn is set to "yes", the cleared tiles remain clear until {{tag||reset_fog}} cancels the clearing. This allows tiles to remain clear for multiple turns, or to be refogged before the end of the current turn (without also refogging all tiles). Multiturn lifted fog is not shared with allies (even when share_view=yes).

=== [reset_fog] ===
{{DevFeature1.11}}The primary use of this tag is to remove multiturn lifted fog (created by {{tag||lift_fog}}), which causes the fog to reset to what it would have been had WML not interfered. (That is, hexes that a side's units could not see at any point this turn will be re-fogged, while seen hexes remain defogged.)
* '''[filter_side]''' with a [[StandardSideFilter]] indicating which sides should be affected.
* [[StandardLocationFilter]]: the fog reset will be restricted to these tiles.
* '''reset_view''': ''yes/no, default: no'' If set to "yes", then in addition to removing multiturn fog, the side's current view is canceled (independent of the SLF). This means that all hexes will become fogged for the side unless multiturn fog exists outside the tiles selected by the SLF. Normally, one would want the currently seen hexes to become clear of fog; this is done automatically at the end of many events, and it can be done manually with {{tag|InterfaceActionsWML|redraw}}.
Omitting both the SSF and the SLF would cancel all earlier uses of [lift_fog].
Additionally setting reset_view="yes" would cause the side's entire map to be fogged (unless an ally keeps hexes clear by sharing its view).

=== [allow_undo] ===

Normally when an event with a handler fires, the player's undo stack is cleared, preventing all actions performed so far from being undone. Including this tag in the event handler prevents the stack from being cleared for this reason, allowing the player to undo actions. (However, the stack might still be cleared for other reasons, such as fog being cleared or combat occurring.) In the common cases, this means '''[allow_undo]''' allows the current action to be undone even though an event was handled. There is a less common case, though — specifically when handling a menu item, where there is no current action — and in this case, '''[allow_undo]''' means merely that earlier actions can still be undone.
* {{DevFeature1.11}} Using this tag in a menu item has an additional side effect in 1.11. Starting with version 1.11.1, executing a WML menu item normally counts as doing something as far as the "you have not started your turn yet" dialog is concerned. However, a menu item whose handler includes '''[allow_undo]''' will not count.

This tag does nothing during recruit and recall actions, as the game incorrectly ignores whether or not an event fired during those times. {{DevFeature1.11}} This has been fixed in the latest development release.

The types of actions that can be undone are movement, recruitment, recalling, and dismissing a unit from the recall list. If an action is undone, only the position (or existence) of the involved unit will be restored; any altered variables or changes to the game will remain changed after the action is undone. It is up to the scenario designer to avoid abusing this command.
* Technically, if '''[allow_undo]''' is inside an '''[event]''' with ''first_time_only=yes'' (the default setting), and the user undoes the event, then the state of the game has changed in this way: the event will not fire a second time, even though the user undid the action the first time.

=== [heal_unit] ===
Heal a unit. The variable '''$heal_amount''' will be set to the exact number of points healed (i.e can be lesser than the parameter '''amount''' if the unit is fully healed). $heal_amount contains only the number of hitpoints the first unit that was found got healed.
* '''[filter]''': [[StandardUnitFilter]] All matching on-map units are healed. If no filter is supplied, it is tried to take the unit at $x1, $y1.
* '''[filter_second]''': [[StandardUnitFilter]] all the units matching the filter ''and'' having the ''heals'' ability will have their animation played (if ''animate'' is set to true) for each of the units healed.
* '''amount''': (integer, default full) the maximum points the unit(s) will be healed. Can't set below 1 or above max_hitpoints. If "full", sets hitpoints to max_hitpoints. Before 1.9 the default is 0.
* '''animate''': a boolean which indicate if the healing animations must be played. (default no)
* '''moves''': (integer, default 0) The maximum current movement points the units will be "healed". Can't set below 0 or above max_moves. If "full", sets moves to max_moves.
* '''restore_attacks''': (boolean, default no) Whether the units' attacks_left should be reset to their max_attacks (usually 1).
* '''restore_statuses''': (boolean, default yes) Whether standard statuses should be reset to "no". This affects poisoned, slowed, petrified and unhealable. Before 1.9 this is always "no".

=== [harm_unit] ===
Harms every unit matching the filter, for the specific damage amount.
* '''[filter]''': [[StandardUnitFilter]] all matching units will be harmed (required).
* '''[filter_second]''': [[StandardUnitFilter]] if present, the first matching unit will attack all the units matching the filter above.
* '''amount''': the amount of damage that will be done (required).
* '''alignment''': (default neutral) applies an alignment to the damage, this means that if alignment=chaotic, the damage will be increased at night and reduced at day.
* '''damage_type''': if present, amount will be altered by unit resistance to the damage type specified.
* '''kill''': (default yes) if yes, when a harmed unit goes to or below 0 HP, it is killed; if no its HP are set to 1.
* '''fire_event''': (default no) if yes, when a unit is killed by harming, the corresponding events are fired.
* '''animate''': (default no) if yes, scrolls to each unit before harming it and plays its defense (or attack, if it's the harmer) and death animations. Special values supported, other than the usual yes and no, are "attacker", that means only the harmer will be animated, and "defender", that means only the harmed units will be animated.
* '''[primary_attack], [secondary_attack]''': these set the weapon against which the harmed units will defend, and that the harming unit will use to attack, respectively (notice this is the opposite of '''[filter]''' and '''[filter_second]''' above). This allows for playing specific defense and attack animations. Both tags are expected to contain a [[FilterWML#Filtering_Weapons|Standard Weapon Filter]].
* '''delay''': if animate=yes, sets the delay (in milliseconds, default 500) between each unit harming.
* '''variable''': if present, the damage caused to the unit, altered by resistances, will be stored in a WML array with the given name, under the "harm_amount" key.
* '''poisoned, slowed, petrified, unhealable''': (default no) if yes, every harmed unit that doesn't already have such status will have it set.
* '''experience''': if yes, and there is a harmer, experience will be attributed like in regular combat.
* '''resistance_multiplier''': {{DevFeature1.11}} the harmed unit's resistance is multiplied by the supplied value; this means that a value lower than 1 increases it, and a value greater than 1 decreases it. Default value is 1, that means no modification.

=== [time_area] ===
How a day should progress in a given area. Everywhere not specified in a [time_area] tag is affected by the [time] tags in the [scenario] tag.
* [[StandardLocationFilter]]: the locations to affect. ''note: only for [event][time_area]s - at scenario toplevel [time_area] does not support [[StandardLocationFilter]], only location ranges''
* [[TimeWML]]: the new schedule.
* '''id''': an unique identifier assigned to a time_area. Optional, unless you want to remove the time_area later. Can be a comma-separated list when removing time_areas, see below.
* '''remove''': (boolean) yes/no value. Indicates whether the specified time_area should be removed. Requires an identifier. If no identifier is used, however, all time_areas are removed.

''Example:'' (caves in parts of a map)
[time_area]
x=1-2,4-5
y=1-2,1-2
{UNDERGROUND}
[/time_area]

=== [end_turn] ===
End the current side's turn. The current event is finished before the turn is ended. Also, if the current event (where the tag appears) has been fired by another event, that event (and the complete stack of other possible parent events) is ended before [end_turn] comes into affect. Also, events following the event stack that fired [end_turn] are not omitted (e.g. [end_turn] is used by a side turn event and a turn refresh event does something afterwards).

=== [replace_map] ===

Replaces the entire map.
* '''map''': Content of a wesnoth map file. example:
map="{campaigns/Heir_To_The_Throne/maps/01_The_Elves_Besieged.map}"
* '''expand''': if 'yes', allows the map size to increase. The expansion direction is currently always bottom-right.
* '''shrink''': if 'yes', allows the map size to decrease. If the map size is reduced, any units that would no longer be on the map due to its coordinates no longer existing will be put into the recall list.
Note: When a hex changes from a village terrain to a non-village terrain, and a team owned that village it loses that village. When a hex changes from a non-village terrain to a village terrain and there is a unit on that hex it does not automatically capture the village. The reason for not capturing villages it that there are too many choices to make; should a unit loose its movement points, should capture events be fired. It is easier to do this as wanted by the author in WML.

=== [replace_schedule] ===
Replace the time of day schedule of the entire scenario.
* [[TimeWML]]: the new schedule.

=== [tunnel] ===

Create a tunnel between some locations, later usable by units to move from source hex to target hex (using the movement cost of unit on the target terrain). ([http://forums.wesnoth.org/viewtopic.php?f=21&t=14749&p=405667&hilit=tunnel#p405667 source])

* '''id''' identifier for the tunnel, to allow removing (optional).
* '''remove''': (boolean) yes/no value. If yes, removes all defined tunnels with the same ID (then only id= is necessary). (default: no)
* '''bidirectional''': (boolean) if yes, creates also a tunnel in the other direction. (default: yes)
* '''always_visible''': (boolean) if yes, the possible movement of enemies under fog can be seen. (default: no)
* '''[source]''': [[StandardLocationFilter]] the source hex(es) (required).
* '''[target]''': [[StandardLocationFilter]] the target hex(es) (required).
* '''[filter]''': [[StandardUnitFilter]] the units which can use the tunnel (required). Leave empty for "all units".

(Note: The tunnel tag can also be used inside the [[AbilitiesWML|[teleport]]] ability, without remove= and id=).

== Useful Macros ==
There are some predefined macros that you find useful for direct actions. You can find a complete list along with a detailed explanation of how they work [http://www.wesnoth.org/macro-reference.xhtml here].
* '''{MOVE_UNIT}''': Moves a unit to another location in the map and the player sees the movement (unlike [teleport])
* '''{FULL_HEAL}''': Brings a unit to full HP
* '''{LOYAL_UNIT}''': Create a loyal unit
* '''{MODIFY_TERRAIN_MASK}''': Modify an area of terrain

== See Also ==

* [[InternalActionsWML]]
* [[InterfaceActionsWML]]
* [[EventWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]
[[Category: ActionsWML]]

Fosdem2013

2013-02-01T08:59:14Z

SkeletonCrew: /* Schedule/Plans */

== General information ==
This page is meant to somehow coordinate the small Wesconf taking place at FOSDEM 2013. That is everyone attending should please list themself in the list of arrivals and stuff like this. FOSDEM 2013 will take place at the first weekend in Febuary 2013, on Saturday 2nd and Sunday 3rd.

* Fosdem - https://fosdem.org/2013/
* [https://mail.gna.org/public/wesnoth-dev/2012-12/msg00003.html Wesnoth-dev planning post]

== Schedule/Plans ==
{| border="1" width="100%"
|-
! (nick)name(s)
! Arrival
! Departure
! Accomodation
|-
| AI
| Fri, 1st (?)
| Sun, 3rd (?)
| 2go4 (booked by Ivanovic)
|-
| boucman
| Fri, 1st (?)
| Sun, 3rd (?)
| ? (probably not 2go4)
|-
| elias
| Fri, 1st, 16:50 @airport
| Sun, 3rd
| ibis Brussels off Grand'Place
|-
| Crab_ and wife
| Fri, 1st (arriving at the airport at ~17:10)
| sometime the week afterwards
| ? (not 2go4)
|-
| fendrin
| Fri, 1st, "afternoon" (~17:00 at "chokopolis"; by car with Ivanovic)
| Sun, 3rd (?)
| 2go4 (booked by Ivanovic)
|-
| Ivanovic
| Fri, 1st, "afternoon" (~17:00 at "chokopolis"; not 100% sure yet)
| Sun, 3rd, leaving right from ULB campus
| 2go4 (booked by Ivanovic)
|-
| mordante
| Fri, 1st "afternoon" (~16:00 at chokopolis" or the Greek)
| Sun, 3rd evening
| 2go4 (booked by Ivanovic)
|-
|-
| yogibear + children
| Fri, 1st afternoon
| Sun, 3rd evening
| Novotel
|-
|}

For accommodations please keep in mind that parking in the center of Brussels is really problematic. It might make sense to drive to the University where FOSDEM takes place, park there and take the bus into the town center (where some of the hotels/hostels are).

Possible hostels that we at least contacted over the last years (some of them might already be booked out by now!):
* [http://www.chab.be/ CHAB]
* [http://www.2go4.be/ 2go4] Note: groups bigger 6 are not allowed, so we can (officially) not form a complete Wesnoth group at this hostel if we are more than 6 guys staying there, got to meet somewhere in town/at the university...
* [http://www.jeugdherbergen.be/brusselE.htm Bruegel YH]

On the official FOSDEM page [https://fosdem.org/2013/practical/accommodation/ some more possible hotels/hostels] are listed.

== Maps ==
* [http://tinyurl.com/3a65gr Bruegel YH]
* [http://tinyurl.com/35br9c Brussels Central (Train Station) → Bruegel YH]
* [http://tinyurl.com/37d9v4 Bruegel YH → Brussels Central (Train Station) → Novotel Grand Place]
* [http://tinyurl.com/2mzns6 Novotel Grand Place]
* [http://tinyurl.com/3dggg3 CrownePlaza (Europa)]
* [http://tinyurl.com/36epxj FOSDEM]
* [http://tinyurl.com/2w4bms Novotel Grand Place -> FOSDEM]

== Transportation ==
Information about how to reach the FOSDEM is listed at the [https://fosdem.org/2013/practical/transportation/ official transportation subpage].

Short version of how to get there for those that reside in Bruegel YH and Novotel Grand Place (basically town center):

* Enter Bus 71 (Debrouckere - Central Station ("Gare Centrale") - Delta) somewhere at 'Central Station'
* Leave the bus at "ULB" (crossroads Ave. Adolphe Buyl - Sq. Deveze)
* Walk down Ave. Paul Heger on your right hand.

== Wesnoth Hacking Room ==

Wesnoth will not have a room of its own (though there will be the open source game dev devroom on Sunday where hopefully many Wesnoth devs will participate). Instead we will use one of the "general hacking rooms". So far it is not sure which room it will be, if we do it like the last years, it will be room number 115 in the building AW1. Last year this was the smaller of the two hacking rooms and we had no real problem with conquering (and holding) the first row in this room. There were not too many power outlets, so this year at least Ivanovic will bring one multi-outlet power strip plus some extension cable (5m or something like this). There is no wired network, everything wireless (and sometimes rather/very unstable!). Beside this you should bring laptops since there are no computers available for hacking.

Short version:
AW1 - Room 115 (at least on Saturday)

== Discussions and Results ==
We usually discuss all sorts of things at FOSDEM, this section is basically a (really short) summary of things that were discussed including their results. First are the discussions that were done "in plenum" with basically all attendees around. At the bottom is an area meant for discussions that were held in sub groups that not all devs might be aware of that were around.

If you plan any discussions with the other Wesnoth folks, please list them below. After having had the discussion, please make sure to at least post some short words about the topic and the results.

===Placeholder Topic===
Placeholder text for a (planned or past) discussion

===The Open Source Game Development Devroom===
Ivanovic organized another Open Source Game Development Devroom which will take place on Sunday 3rd in room AW1.125. At least two Wesnoth team members plan to hold a talk: Boucman about the Wesnoth animation engine and Ivanovic about translations of open source games. The [https://fosdem.org/2013/schedule/track/open_source_game_development/ schedule] is already available on the fosdem website.

If you want to have an idea what was talked about last year, just have a look at the old [http://fosdem.org/2012/schedule/track/open_source_game_development_devroom schedule with many interesting talks and presentations]. On the talks pages you will often find the presentation slides and sometimes even audio recordings.

== Group Picture ==
The last group picture was taken in 2011. Maybe someone should bring a camera so that we can take a new one this year?

== Previous Years ==
* [http://www.wesnoth.org/wiki/Fosdem2012 FOSDEM 2012 wiki page]
* [http://www.wesnoth.org/wiki/Fosdem2011 FOSDEM 2011 wiki page]
* [http://www.wesnoth.org/wiki/Fosdem2010 FOSDEM 2010 wiki page]
* [http://www.wesnoth.org/wiki/Fosdem2009 FOSDEM 2009 wiki page]
* [http://www.wesnoth.org/wiki/Fosdem2008 2008 wiki page], [http://www.wesnoth.org/forum/viewtopic.php?p=283649#p283649 Forum topic (with group photo)], [https://mail.gna.org/public/wesnoth-dev/2008-02/msg00078.html Summary of FOSDEM 2008 results]

[[Category:Development]]
[[Category:Wesconf]]

TerrainCodeTableWML

2012-04-30T20:21:48Z

SkeletonCrew: autogenerated

{{AutogeneratedWML}}{| border="1"
!terrain
!name
!string
!alias of
!editor group
|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/ocean-grey-tile.png
| Gray Deep Water
| Wog
| Wo
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/ocean-tile.png
| Medium Deep Water
| Wo
|
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/ocean-tropical-tile.png
| Tropical Deep Water
| Wot
| Wo
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/coast-grey-tile.png
| Gray Shallow Water
| Wwg
| Ww
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/coast-tile.png
| Medium Shallow Water
| Ww
|
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/coast-tropical-tile.png
| Tropical Shallow Water
| Wwt
| Ww
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/ford-tile.png
| Ford
| Wwf
| Gt, Ww
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/reef-gray-tile.png
| Gray Coastal Reef
| Wwrg
| Wwr
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/reef-tile.png
| Coastal Reef
| Wwr
|
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/reef-tropical-tile.png
| Tropical Coastal Reef
| Wwrt
| Wwr
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/swamp/water-tile.png
| Swamp
| Ss
|
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/swamp/mud-tile.png
| Muddy Quagmire
| Sm
| Ss
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/grass/green.png
| Green Grass
| Gg
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/grass/semi-dry.png
| Semi-dry Grass
| Gs
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/grass/dry.png
| Dry Grass
| Gd
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/grass/leaf-litter.png
| Leaf Litter
| Gll
| Gt
| flat,fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/flat/dirt-dark.png
| Dark Dirt
| Rb
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/flat/dirt.png
| Regular Dirt
| Re
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/flat/desert-road.png
| Dry Dirt
| Rd
| Gt
| desert, flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/flat/road.png
| Regular Cobbles
| Rr
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/flat/road-clean.png
| Clean Gray Cobbles
| Rrc
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/flat/stone-path.png
| Overgrown Cobbles
| Rp
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/frozen/ice.png
| Ice
| Ai
| At
| frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/frozen/snow.png
| Snow
| Aa
| At
| frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/sand/desert.png
| Desert Sands
| Dd
| Ds
| desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/sand/beach.png
| Beach Sands
| Ds
|
| desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/sand/desert-oasis.png
| Oasis
| ^Do
| _bas
| desert, forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/misc/rubble-tile.png
| Rubble
| ^Dr
| _bas, Hh
| desert, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/sand/crater.png
| Crater
| Dd^Dc
| Ds
| desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/flowers-mixed.png
| Mixed Flowers
| ^Efm
| _bas
| embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/farm-veg-spring-icon.png
| Farmland
| ^Gvs
| _bas
| embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/stones-small7.png
| Stones
| ^Es
| _bas
| embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/mushroom.png
| Small Mushrooms
| ^Em
| _bas
| embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/mushroom-farm-small.png
| Mushroom Farm
| ^Emf
| _bas
| embellishments,cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/desert-plant5.png
| Desert Plants
| ^Edp
| _bas
| embellishments, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/desert-plant.png
| Desert Plants without Bones
| ^Edpp
| _bas
| embellishments, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/misc/windmill-embellishment-tile.png
| Windmill
| ^Wm
| _bas
| embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/misc/fire-A01.png
| Campfire
| ^Ecf
| _bas
| embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/fence-se-nw-01.png
| Fence
| ^Eff
| _bas
| embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/rocks.png
| Stones with Sand Drifts
| ^Esd
| _bas
| embellishments, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/water-lilies-tile.png
| Water Lilies
| ^Ewl
| _bas
| water,embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/water-lilies-flower-tile.png
| Flowering Water Lilies
| ^Ewf
| _bas
| water,embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/great-tree-tile.png
| Great Tree
| ^Fet
| _bas,Ft
| forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/great-tree-dead-tile.png
| Dead Great Tree
| ^Fetd
| _bas,Ft
| forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/tropical-tile.png
| Tropical Forest
| ^Ft
| _bas,Ft
| forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/palm-desert-tile.png
| Palm Forest
| ^Ftd
| _bas,Ft
| forest,desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/pine-tile.png
| Pine Forest
| ^Fp
| _bas,Ft
| forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/snow-forest-tile.png
| Snowy Pine Forest
| ^Fpa
| _bas,At,Ft
| frozen, forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/deciduous-summer-tile.png
| Summer Deciduous Forest
| ^Fds
| _bas,Ft
| forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/deciduous-fall-tile.png
| Fall Deciduous Forest
| ^Fdf
| _bas,Ft
| forest, fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/deciduous-winter-tile.png
| Winter Deciduous Forest
| ^Fdw
| _bas,Ft
| forest, fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/deciduous-winter-snow-tile.png
| Snowy Deciduous Forest
| ^Fda
| _bas,At,Ft
| frozen, forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/mixed-summer-tile.png
| Summer Mixed Forest
| ^Fms
| _bas,Ft
| forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/mixed-fall-tile.png
| Fall Mixed Forest
| ^Fmf
| _bas,Ft
| forest, fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/mixed-winter-tile.png
| Winter Mixed Forest
| ^Fmw
| _bas,Ft
| forest, fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/mixed-winter-snow-tile.png
| Snowy Mixed Forest
| ^Fma
| _bas,At,Ft
| frozen, forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/hills/regular.png
| Regular Hills
| Hh
|
| rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/hills/dry.png
| Dry Hills
| Hhd
| Hh
| rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/hills/desert.png
| Dunes
| Hd
| Ds, Hh
| desert, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/hills/snow.png
| Snow Hills
| Ha
| At, Hh
| frozen, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/mountains/basic-tile.png
| Mountains
| Mm
|
| rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/mountains/dry-tile.png
| Dry Mountains
| Md
| Mm
| rough, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/mountains/snow-tile.png
| Snowy Mountains
| Ms
| At, Mm
| rough, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-hills-tile.png
| Forested Hills
| Hh^Fp
| Hh,Ft
| forest, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-snow-hills-tile.png
| Forested Snow Hills
| Ha^Fpa
| Hh,At,Ft
| forest, rough, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-deciduous-summer-hills-tile.png
| Summer Deciduous Forested Hills
| Hh^Fds
| Hh,Ft
| forest, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-deciduous-fall-hills-tile.png
| Fall Deciduous Forested Hills
| Hhd^Fdf
| Hh,Ft
| forest, rough, fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-deciduous-winter-hills-tile.png
| Winter Deciduous Forested Hills
| Hhd^Fdw
| Hh,Ft
| forest, rough, fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-deciduous-winter-snow-hills-tile.png
| Snowy Deciduous Forested Hills
| Ha^Fda
| Hh,At,Ft
| frozen, forest, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-mixed-summer-hills-tile.png
| Summer Mixed Forested Hills
| Hh^Fms
| Hh,Ft
| forest, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-mixed-fall-hills-tile.png
| Fall Mixed Forested Hills
| Hhd^Fmf
| Hh,Ft
| forest, rough, fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-mixed-winter-hills-tile.png
| Winter Mixed Forested Hills
| Hhd^Fmw
| Hh,Ft
| forest, rough, fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-mixed-winter-snow-hills-tile.png
| Snowy Mixed Forested Hills
| Ha^Fma
| Hh,At,Ft
| frozen, forest, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-tropical-hills-tile.png
| Tropical Forested Hills
| Hh^Ft
| Hh,Ft
| forest, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/palms-on-dunes-tile.png
| Palm Forested Hills
| Hd^Ftd
| Hh,Ds,Ft
| desert, forest, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/interior/wood-regular.png
| Basic Wooden Floor
| Iwr
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/beam-tile.png
| Beam of Light
| ^Ii
| _bas
| cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/floor6.png
| Cave Floor
| Uu
|
| cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/earthy-floor3.png
| Earthy Cave Floor
| Uue
| Uu
| cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/flagstones-dark.png
| Dark Flagstones
| Urb
| Gt

| cave, flat
|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/path.png
| Cave Path
| Ur
| Gt
| cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/mushrooms-tile.png
| Mushroom Grove
| ^Uf
|
| cave, forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/mushrooms-beam-tile.png
| Lit Mushroom Grove
| ^Ufi
| ^Uf
| cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/hills-variation.png
| Rockbound Cave
| Uh
| Uu, Hh
| cave, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/misc/rails-n-s.png
| Mine Rail
| ^Br¦
| _bas,Rt
| cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/misc/rails-ne-sw.png
| Mine Rail
| ^Br/
| _bas,Rt
| cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/misc/rails-se-nw.png
| Mine Rail
| ^Br\
| _bas,Rt
| cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/chasm/regular-tile.png
| Regular Chasm
| Qxu
| Qt
| cave, obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/chasm/earthy-tile.png
| Earthy Chasm
| Qxe
| Qt
| cave, obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/chasm/abyss-tile.png
| Ethereal Abyss
| Qxua
| Qt
| cave, obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/unwalkable/lava-chasm-tile.png
| Lava Chasm
| Ql
| Qt
| cave, obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/unwalkable/lava.png
| Lava
| Qlf
| Qt
| cave, obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/mountains/volcano-tile.png
| Volcano
| Mv
| Qt
| rough, obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/mountains/cloud-tile.png
| Regular Impassable Mountains
| Mm^Xm
| Xt
| rough,obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/mountains/cloud-desert-tile.png
| Desert Impassable Mountains
| Md^Xm
| Xt
| rough,obstacle,desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/mountains/cloud-snow-tile.png
| Snowy Impassable Mountains
| Ms^Xm
| Xt
| rough,obstacle,frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/wall-rough-tile.png
| Natural Cave Wall
| Xu
| Xt
| cave,obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/wall-hewn-tile.png
| Hewn Cave Wall
| Xuc
| Xt
| cave,obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/earthy-wall-rough-tile.png
| Natural Earthy Cave Wall
| Xue
| Xt
| cave,obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/earthy-wall-hewn-tile.png
| Reinforced Earthy Cave Wall
| Xuce
| Xt
| cave,obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/walls/wall-stone-tile.png
| Stone Wall
| Xos
| Xt
| cave,obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/walls/wall-stone-tile.png
| Lit Stone Wall
| Xol
| Xt
| cave,obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/impassable-editor.png
| Impassable Overlay
| ^Xo
| _bas,Xt
| special

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/void/void-editor.png
| Void
| Xv
| Xt
| obstacle, special

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/desert-tile.png
| Adobe Village
| ^Vda
| _bas, Vi
| village, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/desert-camp-tile.png
| Desert Tent Village
| ^Vdt
| _bas, Vi
| village, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/camp-tile.png
| Tent Village
| ^Vct
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/orc-tile.png
| Orcish Village
| ^Vo
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/orc-snow-tile.png
| Snowy Orcish Village
| ^Voa
| _bas, Vi
| village, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/elven-snow-tile.png
| Snowy Elven Village
| ^Vea
| _bas, Vi
| village, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/elven-tile.png
| Elven Village
| ^Ve
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/human-tile.png
| Cottage
| ^Vh
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/snow-tile.png
| Snowy Cottage
| ^Vha
| _bas, Vi
| village, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/human-cottage-ruin-tile.png
| Ruined Cottage
| ^Vhr
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/human-city-tile.png
| Human City
| ^Vhc
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/misc/windmill-tile.png
| Windmill Village
| ^Vwm
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/human-city-snow-tile.png
| Snowy Human City
| ^Vhca
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/human-city-ruin-tile.png
| Ruined Human City
| ^Vhcr
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/human-hills-tile.png
| Hill Stone Village
| ^Vhh
| _bas, Vi
| village, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/human-snow-hills-tile.png
| Snowy Hill Stone Village
| ^Vhha
| _bas, Vi
| village, frozen, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/human-hills-ruin-tile.png
| Ruined Hill Stone Village
| ^Vhhr
| _bas, Vi
| village, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/tropical-tile.png
| Tropical Village
| ^Vht
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/drake-tile.png
| Drake Village
| ^Vd
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/cave-tile.png
| Cave Village
| ^Vu
| _bas, Vi
| village, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/dwarven-tile.png
| Dwarven Village
| ^Vud
| _bas, Vi
| village, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/hut-tile.png
| Hut
| ^Vc
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/hut-snow-tile.png
| Snowy Hut
| ^Vca
| _bas, Vi
| village, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/log-cabin-tile.png
| Log Cabin
| ^Vl
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/log-cabin-snow-tile.png
| Snowy Log Cabin
| ^Vla
| _bas, Vi
| village, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/igloo-tile.png
| Igloo
| ^Vaa
| _bas, Vi
| village, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/swampwater-tile.png
| Swamp Village
| ^Vhs
| _bas, Vi
| water, village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/coast-tile.png
| Merfolk Village
| ^Vm
| _bas
| water, village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/village-overlay-editor.png
| Village Overlay
| ^Vov
| _bas
| village, special

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/encampment/regular-tile.png
| Encampment
| Ce
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/encampment/snow-tile.png
| Snowy Encampment
| Cea
| Ch
| castle, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/orcish/tile.png
| Orcish Castle
| Co
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/winter-orcish/tile.png
| Snowy Orcish Castle
| Coa
| Ch
| castle, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/castle-tile.png
| Human Castle
| Ch
|
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/snowy/castle-tile.png
| Snowy Human Castle
| Cha
| Ch, At
| castle, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/elven/tile.png
| Elvish Castle
| Cv
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/dwarven-castle-tile.png
| Dwarven Castle
| Cud
| Ch
| castle, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/ruin-tile.png
| Ruined Human Castle
| Chr
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/sunken-ruin-tile.png
| Sunken Human Ruin
| Chw
| Ch, Ww
| castle, water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/swamp-ruin-tile.png
| Swamp Human Ruin
| Chs
| Ch, Ss
| castle, water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/sand/tile.png
| Desert Castle
| Cd
| Ch
| castle, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/sand/ruin-tile.png
| Ruined Desert Castle
| Cdr
| Ch
| castle, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/encampment/regular-keep-tile.png
| Encampment Keep
| Ke
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/encampment/tall-keep-tile.png
| Tall Encampment Keep
| Ket
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/encampment/snow-keep-tile.png
| Snowy Encampment Keep
| Kea
| Ch
| castle, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/orcish/keep-tile.png
| Orcish Keep
| Ko
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/winter-orcish/keep-tile.png
| Snowy Orcish Keep
| Koa
| Ch
| castle, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/keep-tile.png
| Human Castle Keep
| Kh
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/snowy/keep-tile.png
| Snowy Human Castle Keep
| Kha
| Ch, At
| castle, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/elven/keep-tile.png
| Elven Castle Keep
| Kv
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/dwarven-keep-tile.png
| Dwarven Castle Keep
| Kud
| Ch
| castle, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/ruined-keep-tile.png
| Ruined Human Castle Keep
| Khr
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/sunken-keep-tile.png
| Sunken Human Castle Keep
| Khw
| Ch, Ww
| castle, water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/swamp-keep-tile.png
| Swamp Human Castle Keep
| Khs
| Ch, Ss
| castle, water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/sand/keep-tile.png
| Desert Keep
| Kd
| Ch
| castle, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/sand/ruin-keep-tile.png
| Ruined Desert Keep
| Kdr
| Ch
| castle, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/castle-overlay-editor.png
| Castle Overlay
| ^Cov
| _bas
| castle, special

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/keep-overlay-editor.png
| Keep Overlay
| ^Kov
| _bas
| castle, special

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/wood-n-s.png
| Wooden Bridge
| ^Bw¦
| _bas, Gt
| bridge, water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/wood-ne-sw.png
| Wooden Bridge
| ^Bw/
| _bas, Gt
| bridge, water
|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/wood-se-nw.png
| Wooden Bridge
| ^Bw\
| _bas, Gt
| bridge, water
|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/wood-rotting-n-s.png
| Rotting Bridge
| ^Bw¦r
| _bas, Gt
| bridge, water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/wood-rotting-ne-sw.png
| Rotting Bridge
| ^Bw/r
| _bas, Gt
| bridge, water
|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/wood-rotting-se-nw.png
| Rotting Bridge
| ^Bw\r
| _bas, Gt
| bridge, water
|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/stonebridge-n-s-tile.png
| Basic Stone Bridge
| ^Bsb¦
| _bas, Gt
| bridge,water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/stonebridge-se-nw-tile.png
| Basic Stone Bridge
| ^Bsb\
| _bas, Gt
| bridge,water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/stonebridge-ne-sw-tile.png
| Basic Stone Bridge
| ^Bsb/
| _bas, Gt
| bridge,water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/chasm-stone-bridge-s-n-tile.png
| Cave Chasm Bridge
| ^Bs¦
| Uu,_bas
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/chasm-stone-bridge-sw-ne-tile.png
| Cave Chasm Bridge
| ^Bs/
| Uu,_bas
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/chasm-stone-bridge-se-nw-tile.png
| Cave Chasm Bridge
| ^Bs\
| Uu,_bas
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/hanging-se-nw-tile.png
| Hanging Bridge
| ^Bh\
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/hanging-sw-ne-tile.png
| Hanging Bridge
| ^Bh/
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/hanging-s-n-tile.png
| Hanging Bridge
| ^Bh¦
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/chasm-se-nw-tile.png
| Stone Chasm Bridge
| ^Bcx\
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/chasm-sw-ne-tile.png
| Stone Chasm Bridge
| ^Bcx/
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/chasm-s-n-tile.png
| Stone Chasm Bridge
| ^Bcx¦
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/planks-se-nw.png
| Plank Bridge
| ^Bp\
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/planks-sw-ne.png
| Plank Bridge
| ^Bp/
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/planks-s-n.png
| Plank Bridge
| ^Bp¦
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/off-map/offmap-editor.png
| Off Map
| _off^_usr
|
| special, obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/off-map/border-ne-se-s-sw-nw-n.png
| Experimental Fake Map Edge
| ^_fme
|
| special, obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/void/shroud-editor.png
| Shroud
| _s
|
| special

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/fog/fog-editor.png
| Fog
| _f
|
| special

|}

TerrainCodeTableWML

2012-04-30T19:58:42Z

SkeletonCrew: autogenerated

{{AutogeneratedWML}}{| border="1"
!terrain
!name
!string
!alias of
!editor group
|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/ocean-grey-tile.png
| Gray Deep Water
| Wog
| Wo
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/ocean-tile.png
| Medium Deep Water
| Wo
|
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/ocean-tropical-tile.png
| Tropical Deep Water
| Wot
| Wo
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/coast-grey-tile.png
| Gray Shallow Water
| Wwg
| Ww
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/coast-tile.png
| Medium Shallow Water
| Ww
|
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/coast-tropical-tile.png
| Tropical Shallow Water
| Wwt
| Ww
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/ford-tile.png
| Ford
| Wwf
| Gt, Ww
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/reef-gray-tile.png
| Gray Coastal Reef
| Wwrg
| Wwr
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/reef-tile.png
| Coastal Reef
| Wwr
|
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/water/reef-tropical-tile.png
| Tropical Coastal Reef
| Wwrt
| Wwr
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/swamp/water-tile.png
| Swamp
| Ss
|
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/swamp/mud-tile.png
| Muddy Quagmire
| Sm
| Ss
| water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/grass/green.png
| Green Grass
| Gg
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/grass/semi-dry.png
| Semi-dry Grass
| Gs
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/grass/dry.png
| Dry Grass
| Gd
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/grass/leaf-litter.png
| Leaf Litter
| Gll
| Gt
| flat,fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/flat/dirt-dark.png
| Dark Dirt
| Rb
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/flat/dirt.png
| Regular Dirt
| Re
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/flat/desert-road.png
| Dry Dirt
| Rd
| Gt
| desert, flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/flat/road.png
| Regular Cobbles
| Rr
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/flat/road-clean.png
| Clean Gray Cobbles
| Rrc
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/flat/stone-path.png
| Overgrown Cobbles
| Rp
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/frozen/ice.png
| Ice
| Ai
| At
| frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/frozen/snow.png
| Snow
| Aa
| At
| frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/sand/desert.png
| Desert Sands
| Dd
| Ds
| desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/sand/beach.png
| Beach Sands
| Ds
|
| desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/sand/desert-oasis.png
| Oasis
| ^Do
| _bas
| desert, forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/misc/rubble-tile.png
| Rubble
| ^Dr
| _bas, Hh
| desert, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/sand/crater.png
| Crater
| Dd^Dc
| Ds
| desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/flowers-mixed.png
| Mixed Flowers
| ^Efm
| _bas
| embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/farm-veg-spring-icon.png
| Farmland
| ^Gvs
| _bas
| embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/stones-small7.png
| Stones
| ^Es
| _bas
| embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/mushroom.png
| Small Mushrooms
| ^Em
| _bas
| embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/mushroom-farm-small.png
| Mushroom Farm
| ^Emf
| _bas
| embellishments,cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/desert-plant5.png
| Desert Plants
| ^Edp
| _bas
| embellishments, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/desert-plant.png
| Desert Plants without Bones
| ^Edpp
| _bas
| embellishments, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/misc/windmill-embellishment-tile.png
| Windmill
| ^Wm
| _bas
| embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/misc/fire-A01.png
| Campfire
| ^Ecf
| _bas
| embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/fence-se-nw-01.png
| Fence
| ^Eff
| _bas
| embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/rocks.png
| Stones with Sand Drifts
| ^Esd
| _bas
| embellishments, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/water-lilies-tile.png
| Water Lilies
| ^Ewl
| _bas
| water,embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/embellishments/water-lilies-flower-tile.png
| Flowering Water Lilies
| ^Ewf
| _bas
| water,embellishments

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/great-tree-tile.png
| Great Tree
| ^Fet
| _bas,Ft
| forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/great-tree-dead-tile.png
| Dead Great Tree
| ^Fetd
| _bas,Ft
| forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/tropical-tile.png
| Tropical Forest
| ^Ft
| _bas,Ft
| forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/palm-desert-tile.png
| Palm Forest
| ^Ftd
| _bas,Ft
| forest,desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/pine-tile.png
| Pine Forest
| ^Fp
| _bas,Ft
| forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/snow-forest-tile.png
| Snowy Pine Forest
| ^Fpa
| _bas,At,Ft
| frozen, forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/deciduous-summer-tile.png
| Summer Deciduous Forest
| ^Fds
| _bas,Ft
| forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/deciduous-fall-tile.png
| Fall Deciduous Forest
| ^Fdf
| _bas,Ft
| forest, fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/deciduous-winter-tile.png
| Winter Deciduous Forest
| ^Fdw
| _bas,Ft
| forest, fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/deciduous-winter-snow-tile.png
| Snowy Deciduous Forest
| ^Fda
| _bas,At,Ft
| frozen, forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/mixed-summer-tile.png
| Summer Mixed Forest
| ^Fms
| _bas,Ft
| forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/mixed-fall-tile.png
| Fall Mixed Forest
| ^Fmf
| _bas,Ft
| forest, fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/mixed-winter-tile.png
| Winter Mixed Forest
| ^Fmw
| _bas,Ft
| forest, fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/mixed-winter-snow-tile.png
| Snowy Mixed Forest
| ^Fma
| _bas,At,Ft
| frozen, forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/hills/regular.png
| Regular Hills
| Hh
|
| rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/hills/dry.png
| Dry Hills
| Hhd
| Hh
| rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/hills/desert.png
| Dunes
| Hd
| Ds, Hh
| desert, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/hills/snow.png
| Snow Hills
| Ha
| At, Hh
| frozen, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/mountains/basic-tile.png
| Mountains
| Mm
|
| rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/mountains/dry-tile.png
| Dry Mountains
| Md
| Mm
| rough, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/mountains/snow-tile.png
| Snowy Mountains
| Ms
| At, Mm
| rough, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-hills-tile.png
| Forested Hills
| Hh^Fp
| Hh,Ft
| forest, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-snow-hills-tile.png
| Forested Snow Hills
| Ha^Fpa
| Hh,At,Ft
| forest, rough, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-deciduous-summer-hills-tile.png
| Summer Deciduous Forested Hills
| Hh^Fds
| Hh,Ft
| forest, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-deciduous-fall-hills-tile.png
| Fall Deciduous Forested Hills
| Hhd^Fdf
| Hh,Ft
| forest, rough, fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-deciduous-winter-hills-tile.png
| Winter Deciduous Forested Hills
| Hhd^Fdw
| Hh,Ft
| forest, rough, fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-deciduous-winter-snow-hills-tile.png
| Snowy Deciduous Forested Hills
| Ha^Fda
| Hh,At,Ft
| frozen, forest, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-mixed-summer-hills-tile.png
| Summer Mixed Forested Hills
| Hh^Fms
| Hh,Ft
| forest, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-mixed-fall-hills-tile.png
| Fall Mixed Forested Hills
| Hhd^Fmf
| Hh,Ft
| forest, rough, fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-mixed-winter-hills-tile.png
| Winter Mixed Forested Hills
| Hhd^Fmw
| Hh,Ft
| forest, rough, fall

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-mixed-winter-snow-hills-tile.png
| Snowy Mixed Forested Hills
| Ha^Fma
| Hh,At,Ft
| frozen, forest, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/forested-tropical-hills-tile.png
| Tropical Forested Hills
| Hh^Ft
| Hh,Ft
| forest, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/palms-on-dunes-tile.png
| Palm Forested Hills
| Hd^Ftd
| Hh,Ds,Ft
| desert, forest, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/interior/wood-regular.png
| Basic Wooden Floor
| Iwr
| Gt
| flat

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/beam-tile.png
| Beam of Light
| ^Ii
| _bas
| cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/floor6.png
| Cave Floor
| Uu
|
| cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/earthy-floor3.png
| Earthy Cave Floor
| Uue
| Uu
| cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/flagstones-dark.png
| Dark Flagstones
| Urb
| Gt

| cave, flat
|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/path.png
| Cave Path
| Ur
| Gt
| cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/mushrooms-tile.png
| Mushroom Grove
| ^Uf
|
| cave, forest

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/forest/mushrooms-beam-tile.png
| Lit Mushroom Grove
| ^Ufi
| ^Uf
| cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/hills-variation.png
| Rockbound Cave
| Uh
| Uu, Hh
| cave, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/misc/rails-n-s.png
| Mine Rail
| ^Br|
| _bas,Rt
| cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/misc/rails-ne-sw.png
| Mine Rail
| ^Br/
| _bas,Rt
| cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/misc/rails-se-nw.png
| Mine Rail
| ^Br\
| _bas,Rt
| cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/chasm/regular-tile.png
| Regular Chasm
| Qxu
| Qt
| cave, obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/chasm/earthy-tile.png
| Earthy Chasm
| Qxe
| Qt
| cave, obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/chasm/abyss-tile.png
| Ethereal Abyss
| Qxua
| Qt
| cave, obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/unwalkable/lava-chasm-tile.png
| Lava Chasm
| Ql
| Qt
| cave, obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/unwalkable/lava.png
| Lava
| Qlf
| Qt
| cave, obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/mountains/volcano-tile.png
| Volcano
| Mv
| Qt
| rough, obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/mountains/cloud-tile.png
| Regular Impassable Mountains
| Mm^Xm
| Xt
| rough,obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/mountains/cloud-desert-tile.png
| Desert Impassable Mountains
| Md^Xm
| Xt
| rough,obstacle,desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/mountains/cloud-snow-tile.png
| Snowy Impassable Mountains
| Ms^Xm
| Xt
| rough,obstacle,frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/wall-rough-tile.png
| Natural Cave Wall
| Xu
| Xt
| cave,obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/wall-hewn-tile.png
| Hewn Cave Wall
| Xuc
| Xt
| cave,obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/earthy-wall-rough-tile.png
| Natural Earthy Cave Wall
| Xue
| Xt
| cave,obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/earthy-wall-hewn-tile.png
| Reinforced Earthy Cave Wall
| Xuce
| Xt
| cave,obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/walls/wall-stone-tile.png
| Stone Wall
| Xos
| Xt
| cave,obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/walls/wall-stone-tile.png
| Lit Stone Wall
| Xol
| Xt
| cave,obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/impassable-editor.png
| Impassable Overlay
| ^Xo
| _bas,Xt
| special

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/void/void-editor.png
| Void
| Xv
| Xt
| obstacle, special

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/desert-tile.png
| Adobe Village
| ^Vda
| _bas, Vi
| village, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/desert-camp-tile.png
| Desert Tent Village
| ^Vdt
| _bas, Vi
| village, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/camp-tile.png
| Tent Village
| ^Vct
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/orc-tile.png
| Orcish Village
| ^Vo
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/orc-snow-tile.png
| Snowy Orcish Village
| ^Voa
| _bas, Vi
| village, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/elven-snow-tile.png
| Snowy Elven Village
| ^Vea
| _bas, Vi
| village, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/elven-tile.png
| Elven Village
| ^Ve
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/human-tile.png
| Cottage
| ^Vh
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/snow-tile.png
| Snowy Cottage
| ^Vha
| _bas, Vi
| village, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/human-cottage-ruin-tile.png
| Ruined Cottage
| ^Vhr
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/human-city-tile.png
| Human City
| ^Vhc
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/misc/windmill-tile.png
| Windmill Village
| ^Vwm
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/human-city-snow-tile.png
| Snowy Human City
| ^Vhca
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/human-city-ruin-tile.png
| Ruined Human City
| ^Vhcr
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/human-hills-tile.png
| Hill Stone Village
| ^Vhh
| _bas, Vi
| village, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/human-snow-hills-tile.png
| Snowy Hill Stone Village
| ^Vhha
| _bas, Vi
| village, frozen, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/human-hills-ruin-tile.png
| Ruined Hill Stone Village
| ^Vhhr
| _bas, Vi
| village, rough

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/tropical-tile.png
| Tropical Village
| ^Vht
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/drake-tile.png
| Drake Village
| ^Vd
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/cave-tile.png
| Cave Village
| ^Vu
| _bas, Vi
| village, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/dwarven-tile.png
| Dwarven Village
| ^Vud
| _bas, Vi
| village, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/hut-tile.png
| Hut
| ^Vc
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/hut-snow-tile.png
| Snowy Hut
| ^Vca
| _bas, Vi
| village, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/log-cabin-tile.png
| Log Cabin
| ^Vl
| _bas, Vi
| village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/log-cabin-snow-tile.png
| Snowy Log Cabin
| ^Vla
| _bas, Vi
| village, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/igloo-tile.png
| Igloo
| ^Vaa
| _bas, Vi
| village, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/swampwater-tile.png
| Swamp Village
| ^Vhs
| _bas, Vi
| water, village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/coast-tile.png
| Merfolk Village
| ^Vm
| _bas
| water, village

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/village/village-overlay-editor.png
| Village Overlay
| ^Vov
| _bas
| village, special

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/encampment/regular-tile.png
| Encampment
| Ce
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/encampment/snow-tile.png
| Snowy Encampment
| Cea
| Ch
| castle, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/orcish/tile.png
| Orcish Castle
| Co
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/winter-orcish/tile.png
| Snowy Orcish Castle
| Coa
| Ch
| castle, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/castle-tile.png
| Human Castle
| Ch
|
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/snowy/castle-tile.png
| Snowy Human Castle
| Cha
| Ch, At
| castle, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/elven/tile.png
| Elvish Castle
| Cv
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/dwarven-castle-tile.png
| Dwarven Castle
| Cud
| Ch
| castle, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/ruin-tile.png
| Ruined Human Castle
| Chr
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/sunken-ruin-tile.png
| Sunken Human Ruin
| Chw
| Ch, Ww
| castle, water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/swamp-ruin-tile.png
| Swamp Human Ruin
| Chs
| Ch, Ss
| castle, water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/sand/tile.png
| Desert Castle
| Cd
| Ch
| castle, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/sand/ruin-tile.png
| Ruined Desert Castle
| Cdr
| Ch
| castle, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/encampment/regular-keep-tile.png
| Encampment Keep
| Ke
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/encampment/tall-keep-tile.png
| Tall Encampment Keep
| Ket
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/encampment/snow-keep-tile.png
| Snowy Encampment Keep
| Kea
| Ch
| castle, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/orcish/keep-tile.png
| Orcish Keep
| Ko
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/winter-orcish/keep-tile.png
| Snowy Orcish Keep
| Koa
| Ch
| castle, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/keep-tile.png
| Human Castle Keep
| Kh
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/snowy/keep-tile.png
| Snowy Human Castle Keep
| Kha
| Ch, At
| castle, frozen

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/elven/keep-tile.png
| Elven Castle Keep
| Kv
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/dwarven-keep-tile.png
| Dwarven Castle Keep
| Kud
| Ch
| castle, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/ruined-keep-tile.png
| Ruined Human Castle Keep
| Khr
| Ch
| castle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/sunken-keep-tile.png
| Sunken Human Castle Keep
| Khw
| Ch, Ww
| castle, water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/swamp-keep-tile.png
| Swamp Human Castle Keep
| Khs
| Ch, Ss
| castle, water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/sand/keep-tile.png
| Desert Keep
| Kd
| Ch
| castle, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/sand/ruin-keep-tile.png
| Ruined Desert Keep
| Kdr
| Ch
| castle, desert

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/castle-overlay-editor.png
| Castle Overlay
| ^Cov
| _bas
| castle, special

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/castle/keep-overlay-editor.png
| Keep Overlay
| ^Kov
| _bas
| castle, special

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/wood-n-s.png
| Wooden Bridge
| ^Bw|
| _bas, Gt
| bridge, water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/wood-ne-sw.png
| Wooden Bridge
| ^Bw/
| _bas, Gt
| bridge, water
|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/wood-se-nw.png
| Wooden Bridge
| ^Bw\
| _bas, Gt
| bridge, water
|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/wood-rotting-n-s.png
| Rotting Bridge
| ^Bw|r
| _bas, Gt
| bridge, water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/wood-rotting-ne-sw.png
| Rotting Bridge
| ^Bw/r
| _bas, Gt
| bridge, water
|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/wood-rotting-se-nw.png
| Rotting Bridge
| ^Bw\r
| _bas, Gt
| bridge, water
|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/stonebridge-n-s-tile.png
| Basic Stone Bridge
| ^Bsb|
| _bas, Gt
| bridge,water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/stonebridge-se-nw-tile.png
| Basic Stone Bridge
| ^Bsb\
| _bas, Gt
| bridge,water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/stonebridge-ne-sw-tile.png
| Basic Stone Bridge
| ^Bsb/
| _bas, Gt
| bridge,water

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/chasm-stone-bridge-s-n-tile.png
| Cave Chasm Bridge
| ^Bs|
| Uu,_bas
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/chasm-stone-bridge-sw-ne-tile.png
| Cave Chasm Bridge
| ^Bs/
| Uu,_bas
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/cave/chasm-stone-bridge-se-nw-tile.png
| Cave Chasm Bridge
| ^Bs\
| Uu,_bas
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/hanging-se-nw-tile.png
| Hanging Bridge
| ^Bh\
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/hanging-sw-ne-tile.png
| Hanging Bridge
| ^Bh/
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/hanging-s-n-tile.png
| Hanging Bridge
| ^Bh|
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/chasm-se-nw-tile.png
| Stone Chasm Bridge
| ^Bcx\
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/chasm-sw-ne-tile.png
| Stone Chasm Bridge
| ^Bcx/
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/chasm-s-n-tile.png
| Stone Chasm Bridge
| ^Bcx|
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/planks-se-nw.png
| Plank Bridge
| ^Bp\
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/planks-sw-ne.png
| Plank Bridge
| ^Bp/
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/bridge/planks-s-n.png
| Plank Bridge
| ^Bp|
| _bas, Gt
| bridge, cave

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/off-map/offmap-editor.png
| Off Map
| _off^_usr
|
| special, obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/off-map/border-ne-se-s-sw-nw-n.png
| Experimental Fake Map Edge
| ^_fme
|
| special, obstacle

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/void/shroud-editor.png
| Shroud
| _s
|
| special

|-
| http://svn.gna.org/svn/wesnoth/trunk/data/core/images/terrain/fog/fog-editor.png
| Fog
| _f
|
| special

|}

SoC Ideas Addon Server 2012

2012-03-10T10:11:30Z

SkeletonCrew: /* Additional Information */

{{Template:SoC2012Idea}}

=Description=
<h2>Addon Server</h2>
Page for the idea: [[SoC Ideas Addon Server 2012]]

The goal of this project is to write a new addon server for Wesnoth from
scratch.

{{#dpl:
|resultsheader=''There are %PAGES% submitted student proposals for this idea''
|oneresultheader=''There is 1 submitted student proposal for this idea''
|suppresserrors=true
|noresultsheader=''There are no submitted student proposals for this idea''
|category=Summer of Code 2012 Student Page&SoC Ideas IDEA NAME
|notcategory=SoC 2012 Not Submitted To Google
|include=#Description
|nottitlematch=SoC2012_Template_of_Student_page
|mode=userformat
|format=,, See [[%PAGE%|%TITLE%]] for more information. ,
}}

=Additional Information=

The goal is to first help to finish the specifications of the new addon
server (A preliminary version is available in our svn tree as a LaTeX
document, PDF available upon request).

Once the specifications are done the server can be designed and implemented.

=Whom to ask about this=
Mordante on irc

SoC Ideas Addon Server 2012

2012-03-10T10:07:10Z

SkeletonCrew: Initial GSoC Addon server idea

Fosdem2012

2012-02-11T20:34:08Z

SkeletonCrew: /* Discussions and Results */ Added teh contents of my email for the dev-ml

== General information ==
This page is meant to somehow coordinate the small Wesconf taking place at FOSDEM 2012. That is everyone attending should please list him/herself in the list of arrivals and stuff like this. FOSDEM 2012 will take place at the first weekend in Febuary 2012, on Saturday 4th and Sunday 5th.

* Fosdem - http://fosdem.org/2012/

== Schedule/Plans ==
{| border="1" width="100%"
|-
! (nick)name(s)
! Arrival
! Departure
! Accomodation
|-
| AI
| Friday?
| Sunday?
| 2go4 (booked by Ivanovic)
|-
| Boucman
| Fri, 3rd
| Sun, 5th
| not sure, to be confirmed
|-
| Crab
| Fri, 3rd, (Friday 12:20 to Dortmund)
| Sun, 5th (Monday 8:35 from Dortmund)
| 2go4 (booked by Ivanovic)
|-
| elias
| Fri, 3rd, Brussels Midi 18:42
| Sun, 5th
| 2go4 (booked independently)
|-
| fendrin
| Fri, 3rd
| Sun, 5th
| 2go4 (booked by Ivanovic)
|-
| Ivanovic
| Fri, 3rd, "afternoon" (~17:00 at "chokopolis"; not 100% sure yet)
| Sun, 5th, leaving right from ULB campus
| 2go4 (booked by Ivanovic)
|-
| Mordante
| Fri, 3rd
| Sun, 5th
| 2go4 (booked by Ivanovic)
|-
|}

For accommodations please keep in mind that parking in the center of Brussels is really problematic. It might make sense to drive to the University where FOSDEM takes place, park there and take the bus into the town center (where some of the hotels/hostels are).

Possible hostels that we at least contacted over the last years (some of them might already be booked out by now!):
* [http://www.chab.be/ CHAB]
* [http://www.2go4.be/ 2go4] Note: groups bigger 6 are not allowed, so we can (officially) not form a complete Wesnoth group at this hostel, got to meet somewhere in town/at the university...
* [http://www.jeugdherbergen.be/brusselE.htm Bruegel YH]

On the official FOSDEM page [http://www.fosdem.org/2012/practical/accommodation some more possible hotels/hostels] are listed.

== Maps ==
* [http://tinyurl.com/3a65gr Bruegel YH]
* [http://tinyurl.com/35br9c Brussels Central (Train Station) → Bruegel YH]
* [http://tinyurl.com/37d9v4 Bruegel YH → Brussels Central (Train Station) → Novotel Grand Place]
* [http://tinyurl.com/2mzns6 Novotel Grand Place]
* [http://tinyurl.com/3dggg3 CrownePlaza (Europa)]
* [http://tinyurl.com/36epxj FOSDEM]
* [http://tinyurl.com/2w4bms Novotel Grand Place -> FOSDEM]

== Transportation ==
Information about how to reach the FOSDEM is listed at the [http://www.fosdem.org/2012/transportation official transportation subpage].

Short version of how to get there for those that reside in Bruegel YH and Novotel Grand Place (basically town center):

* Enter Bus 71 (Debrouckere - Central Station ("Gare Centrale") - Delta) somewhere at 'Central Station'
* Leave the bus at "ULB" (crossroads Ave. Adolphe Buyl - Sq. Deveze)
* Walk down Ave. Paul Heger on your right hand.

== Wesnoth Hacking Room ==

Wesnoth will not have a room of its own (though there will be the open source game dev devroom on Sunday where hopefully many Wesnoth devs will participate). Instead we will use one of the "general hacking rooms". So far it is not sure which room it will be, if we do it like the last three years, it will be room number 115 in the building AW1 (okay, new booklet is out, now it is AW1.117). Last year this was the smaller of the two hacking rooms and we had no real problem with conquering (and holding) the first row in this room. There were not too many power outlets, so this year at least Ivanovic will bring one multi-outlet power strip plus some extension cable (5m or something like this). Mordante will (hopefully) also bring a multi-outlet power strip and a 20m extension cable. There is no wired network, everything wireless (and sometimes rather/very unstable!). Beside this you should bring laptops since there are no computers available for hacking.

Short version:
AW1 - Room 117 (at least on Saturday)

== Discussions and Results ==
We usually discuss all sorts of things at FOSDEM, this section is basically a (really short) summary of things that were discussed including their results. First are the discussions that were done "in plenum" with basically all attendees around. At the bottom is an area meant for discussions that were held in sub groups that not all devs might be aware of that were around.

Please make sure to list any topics you want to talk about below. The GameDev Room topic might serve as sample...

===Wesnoth presence in the GameDev Room===
Since Ivanovic is responsible for organizing the Open Source Game Development Devroom which takes place on Sunday 5th, there will at least be one Wesnoth Dev busy with this room. Several other devs will hopefully support Ivanovic in this effort and be around to listen to [http://fosdem.org/2012/schedule/track/open_source_game_development_devroom many interesting talks and presentations]. Besides another Wesnoth dev, boucman, will hold a talk about game balancing based on the knowledge the Wesnoth team gathered over time.
===Fun stuff===
*Lua was updated to 5.2 (committed)
*A working prototype was shown for difficulty selection in multiplayer campaigns, turning standard SP campaigns such as Legend of Wesmere or The Son of the Black Eye into multiplayer campaigns with no WML changes invoved.
*AI was tricked to complete a single-player campaign, Two Brothers, in fully unattended mode (no human mouse clicks in scenarios or between them, fully unattended from launch from command-line, until victory in the last scenario)
*AI was tricked to complete An Orcish Incursion campaign
===Mordante's `email'===

Here's my summary of the WESDEM 2012. We met Friday the third after some
delay, traffic in the Netherlands and Belgium is complete chaos as soon as
some snow appears. After a late dinner at the our favourite restaurant we
went to the hostel. Fendrin loves the free wifi in this restaurant.

Saturday we grabbed the hacking room as usual and had some discussions,
whose summaries are below. We also hacked and especially Crab managed to
pull of quite a bit of work. Afterwards we headed for the greek again.

Sunday it was the first time we hosted a devroom and had presentations of
several games. During the first talk the room was not crowded, but that
might have to do with the time, 09:10. With the other talks the room was
crowded or over-crowded. There were several very interesting talks.

I assume Ivanovic will post more information about that event later.
I'd like to thank all speakers for their talks and Ivanovic for his
organisation. The German product `Deutsche Gründlichkeit' is still no
vaporware :-) I think the room was a success and I think we should try to
host another room next year.

Below the details of the discussions at the WESDEM.

Wescamp:

This project has recently moved to Github[1] since Berlios was scheduled
to shut down at the end of last year. AI did this move, but still the
upload of translations doesn't work. Shadow master recently discussed
this as well on the mailing list[2]. Mordante is still interested on
working on this project, but GUI2 has stalled it. Still he's interested to
restart this project in the near future. Some features which were
discussed are:
* The email address will become mandatory. This allows us to contact the author is case there is an issue with the add-on either with the translation or in general, content that is not free, add-on broken, etc. etc..
* The add-on will automatically be uploaded to git if the `translatable' flag is set.
* The translations will be separated from the add-on. This makes it easier to synchronise with Wescamp. In the current set-up the translation is part of the add-on and synchronising means modifying the add-on. This has been one of the reasons for not really pursuing the issue.
* Github has several upload hooks and a JSON API.
* At the client-side there needs to be a preference which translations to download (always including the current language). Then the client can only download the wanted translations. This means the server has to be told which translations to download.
* The replies for the user send by the server should be translatable, like wesnothd.

Mordante has already started a paper with more information regarding this
subject.

[1] Mailinglist is down so link will be added later.
[2] Mailinglist is down so link will be added later.

UI campaigns:

The UI for campaigns was discussed at well. Several ideas were raised,
most referring to some ancient mockups [1]. They still seem to be good
mockups. The idea is make the campaign dialogue to look like [2], but the
list of the campaigns has a small `+' like [3]. When clicked the row
expands like [4], except it shows only difficulty and number of scenarios.

The problems with the current dialogue are:
* Description and information are in one list. This means the engine does not know about things like difficulty and number of scenarios, due to the fact it is `hidden' in the text.
* There needs to be better sorting and filtering of campaigns.

[http://wiki.wesnoth.org/GUI]
[http://exong.net/wesnoth-attach/files/campaign_gui3_205.png]
[http://exong.net/wesnoth-attach/files/download_campaign_dialog3_919.png]
[http://exong.net/wesnoth-attach/files/download_campaign_dialog_exp_208.png]

GSoC:

During the FOSDEM a new Google Summer of Code was announced and the
discussion rose whether to join or not. Some developers thought it might
be an idea to skip a year, others wanted to join. It was decided that it
would be discussed further at this mailing list.

Some points were mentioned:
* GSoC mentoring and preparation cost a lot of time and that time especially mentoring is done by core developers, who can not use that time to hack on Wesnoth.
* The amount of students that stay is rather low. The whole idea of GSoC is to gain new students and keep them. The disadvantages are:
** The project is abandoned after the summer.
** The mentor suddenly has an extra feature to maintain.
** Getting a new student up to speed takes quite some effort, so it would have been faster if the mentor did the work him/herself. This should pay itself back by gaining a new developer. The first happens, the second too little. (That it takes time and is faster to do it oneself is expected, just like training a new colleague.)

Git:

The subject of moving to git was another discussion. For us the main
advantage of git is that it's easier to use with branching and especially
merging branches back. The decentralised work-flow is another plus.
Subversion seems to be working on better branching support, but it is not
expected it will change its centralised work-flow.

Several extra issues were mentioned, these are listed below. Note some of
the points obviously only become valid _if_ we move to git.

* Should be move both the hosting of the code and the bug-tracker at the same time. The idea was that it might be better to do the two separate, but look at the bug-tracker of the new hosting party.
* The integration of the bug-tracker and the commits is an important feature. (If in a commit message bug #xxxxx is mentioned the commit message is posted in the bug as well.)
* The hosting party should have a commit mailing list.
* GNA uses Savannah which seems to be unmaintained, so we might be forced to move anyway, unless GNA switches to another system.
* The GNA bug-tracker is rather nice, the new hosting party should also have a nice tracker. Some trackers were mention:
** Sourceforce's Trac (They also have an older tracker.)
** Gentoo's Bugzilla
* Git has a higher learning curve than Subversion, which can be an issue for non-coder developers:
** Translators, they send a po-file but need to update their repository.
** WML authors.
** Artists, some artists commit themselves. Is git an issue for them? At least Jetryl is familiar with git since he uses it with Frogatto.
** Map balancers, some of them use Subversion others send maps to others with commit rights. (Not discussed on the FOSDEM.)
* The question is how well it git supported on all common platforms:
** Linux obviously supported.
** Mac seems to be supported and have several front-ends.
** Windows has TortoiseGIT which seems to be TortoiseSVN but then using git. This has some advantages, most Windows users use TortoiseSVN so the switch is easy for them. It also `hides' several of the more advanced features of git, which can make git more daunting.
* It was discussed whether it was an idea to move Wesnoth-UMC-dev first but AI mentioned it was planned, but not for the near future.
* Some hosting parties were mentioned as an alternative to GNA.
** Sourceforge
** Github (They have a soft-limit in size of 300 MB, which might be a problem we should ask them before considering.)

== Group Picture ==
Has to be taken first.

== Previous Years ==
* [http://www.wesnoth.org/wiki/Fosdem2011 FOSDEM 2011 wiki page]
* [http://www.wesnoth.org/wiki/Fosdem2010 FOSDEM 2010 wiki page]
* [http://www.wesnoth.org/wiki/Fosdem2009 FOSDEM 2009 wiki page]
* [http://www.wesnoth.org/wiki/Fosdem2008 2008 wiki page], [http://www.wesnoth.org/forum/viewtopic.php?p=283649#p283649 Forum topic (with group photo)], [https://mail.gna.org/public/wesnoth-dev/2008-02/msg00078.html Summary of FOSDEM 2008 results]

[[Category:Development]]
[[Category:Wesconf]]

Fosdem2012

2011-12-17T14:46:00Z

SkeletonCrew: /* Schedule/Plans */ Added myself as FOSDEM visitor

TerrainCodeTableWML

2011-06-19T10:29:39Z

SkeletonCrew: autogenerated

{{AutogeneratedWML}}{| border="1"
!name
!string
!alias of
!editor group
|-
| Gray Deep Water
| Wog
| Wo
| water

|-
| Deep Water
| Wo
|
| water

|-
| Tropical Deep Water
| Wot
| Wo
| water

|-
| Gray Shallow Water
| Wwg
| Ww
| water

|-
| Shallow Water
| Ww
|
| water

|-
| Tropical Shallow Water
| Wwt
| Ww
| water

|-
| Ford
| Wwf
| Gt, Ww
| water

|-
| Coastal Reef
| Wwr
|
| water

|-
| Swamp
| Ss
|
| water

|-
| Muddy Quagmire
| Sm
| Ss
| water

|-
| Green Grass
| Gg
| Gt
| flat

|-
| Semi-dry Grass
| Gs
| Gt
| flat

|-
| Dry Grass
| Gd
| Gt
| flat

|-
| Leaf Litter
| Gll
| Gt
| flat

|-
| Dark Dirt
| Rb
| Gt
| flat

|-
| Regular Dirt
| Re
| Gt
| flat

|-
| Dry Dirt
| Rd
| Gt
| desert, flat

|-
| Regular Cobbles
| Rr
| Gt
| flat

|-
| Clean Gray Cobbles
| Rrc
| Gt
| flat

|-
| Overgrown Cobbles
| Rp
| Gt
| flat

|-
| Ice
| Ai
| At
| frozen

|-
| Snow
| Aa
| At
| frozen

|-
| Desert Sands
| Dd
| Ds
| desert

|-
| Sand
| Ds
|
| desert

|-
| Oasis
| Dd^Do
| Ds
| desert, forest

|-
| Rubble
| ^Dr
| _bas, Hh
| desert, rough

|-
| Crater
| Dd^Dc
| Ds
| desert

|-
| Mixed Flowers
| ^Efm
| _bas
| embellishments

|-
| Farmland
| ^Gvs
| _bas
| embellishments

|-
| Stones
| ^Es
| _bas
| embellishments

|-
| Small Mushrooms
| ^Em
| _bas
| embellishments

|-
| Mushroom Farm
| ^Emf
| _bas
| embellishments,cave

|-
| Desert Plants
| ^Edp
| _bas
| embellishments, desert

|-
| Desert Plants without Bones
| ^Edpp
| _bas
| embellishments, desert

|-
| Windmill
| ^Wm
| _bas
| embellishments

|-
| Fence
| ^Eff
| _bas
| embellishments

|-
| Stones with Sand Drifts
| ^Esd
| _bas
| embellishments, desert

|-
| Water Lilies
| ^Ewl
| _bas
| water,embellishments

|-
| Flowering Water Lilies
| ^Ewf
| _bas
| water,embellishments

|-
| Great Tree
| ^Fet
| ^Fp
| forest

|-
| Dead Great Tree
| ^Fetd
| ^Fp
| forest

|-
| Tropical Forest
| ^Ft
| ^Fp
| forest

|-
| Forest
| ^Fp
|
| forest

|-
| Snowy Pine Forest
| ^Fpa
| At,^Fp
| frozen, forest

|-
| Summer Deciduous Forest
| ^Fds
| ^Fp
| forest

|-
| Fall Deciduous Forest
| ^Fdf
| ^Fp
| forest

|-
| Winter Deciduous Forest
| ^Fdw
| ^Fp
| forest

|-
| Snowy Deciduous Forest
| ^Fda
| At,^Fp
| frozen, forest

|-
| Summer Mixed Forest
| ^Fms
| ^Fp
| forest

|-
| Fall Mixed Forest
| ^Fmf
| ^Fp
| forest

|-
| Winter Mixed Forest
| ^Fmw
| ^Fp
| forest

|-
| Snowy Mixed Forest
| ^Fma
| At,^Fp
| frozen, forest

|-
| Hills
| Hh
|
| rough

|-
| Dry Hills
| Hhd
| Hh
| rough

|-
| Dunes
| Hd
| Ds, Hh
| desert, rough

|-
| Snow Hills
| Ha
| At, Hh
| frozen, rough

|-
| Mountains
| Mm
|
| rough

|-
| Dry Mountains
| Md
| Mm
| rough, desert

|-
| Snowy Mountains
| Ms
| At, Mm
| rough, frozen

|-
| Forested Hills
| Hh^Fp
| Hh,^Fp
| forest, rough

|-
| Forested Snow Hills
| Ha^Fpa
| Ha,^Fp
| forest, rough, frozen

|-
| Summer Deciduous Forested Hills
| Hh^Fds
| Hh,^Fp
| forest, rough

|-
| Fall Deciduous Forested Hills
| Hhd^Fdf
| Hh,^Fp
| forest, rough

|-
| Winter Deciduous Forested Hills
| Hhd^Fdw
| Hh,^Fp
| forest, rough

|-
| Snowy Deciduous Forested Hills
| Ha^Fda
| Ha,^Fp
| frozen, forest, rough

|-
| Summer Mixed Forested Hills
| Hh^Fms
| Hh,^Fp
| forest, rough

|-
| Fall Mixed Forested Hills
| Hhd^Fmf
| Hh,^Fp
| forest, rough

|-
| Winter Mixed Forested Hills
| Hhd^Fmw
| Hh,^Fp
| forest, rough

|-
| Snowy Mixed Forested Hills
| Ha^Fma
| Ha,^Fp
| frozen, forest, rough

|-
| Basic Wooden Floor
| Iwr
| Gt
| flat

|-
| Lit
| ^Ii
| _bas
| cave

|-
| Cave
| Uu
|
| cave

|-
| Earthy Cave Floor
| Uue
| Uu
| cave

|-
| Dark Flagstones
| Urb
| Gt

| cave
|-
| Cave Path
| Ur
| Gt
| cave

|-
| Mushroom Grove
| ^Uf
|
| cave, forest

|-
| Lit Mushroom Grove
| ^Ufi
| ^Uf
| cave

|-
| Rockbound Cave
| Uh
| Uu, Hh
| cave, rough

|-
| Mine Rail
| ^Br|
| _bas
| cave

|-
| Mine Rail
| ^Br/
| _bas
| cave

|-
| Mine Rail
| ^Br\
| _bas
| cave

|-
| Regular Chasm
| Qxu
| Qt
| cave, obstacle

|-
| Earthy Chasm
| Qxe
| Qt
| cave, obstacle

|-
| Ethereal Abyss
| Qxua
| Qt
| obstacle

|-
| Lava Chasm
| Ql
| Qt
| cave, obstacle

|-
| Lava
| Qlf
| Qt
| cave, obstacle

|-
| Volcano
| Mv
| Qt
| rough, obstacle

|-
| Regular Impassable Mountains
| Mm^Xm
| Xt
| rough,obstacle

|-
| Desert Impassable Mountains
| Md^Xm
| Xt
| rough,obstacle,desert

|-
| Snowy Impassable Mountains
| Ms^Xm
| Xt
| rough,obstacle,frozen

|-
| Natural Cave Wall
| Xu
| Xt
| cave,obstacle

|-
| Hewn Cave Wall
| Xuc
| Xt
| cave,obstacle

|-
| Natural Earthy Cave Wall
| Xue
| Xt
| cave,obstacle

|-
| Reinforced Earthy Cave Wall
| Xuce
| Xt
| cave,obstacle

|-
| Stone Wall
| Xos
| Xt
| cave,obstacle

|-
| Lit Stone Wall
| Xol
| Xt
| cave,obstacle

|-
| Impassable Overlay
| ^Xo
| _bas,Xt
| special

|-
| Void
| Xv
| Xt
| obstacle, special

|-
| Adobe Village
| ^Vda
| _bas, Vi
| village, desert

|-
| Desert Tent Village
| ^Vdt
| _bas, Vi
| village, desert

|-
| Tent Village
| ^Vct
| _bas, Vi
| village

|-
| Orcish Village
| ^Vo
| _bas, Vi
| village

|-
| Snowy Orcish Village
| ^Voa
| _bas, Vi
| village, frozen

|-
| Snowy Elven Village
| ^Vea
| _bas, Vi
| village, frozen

|-
| Elven Village
| ^Ve
| _bas, Vi
| village

|-
| Cottage
| ^Vh
| _bas, Vi
| village

|-
| Snowy Cottage
| ^Vha
| _bas, Vi
| village, frozen

|-
| Ruined Cottage
| ^Vhr
| _bas, Vi
| village

|-
| Human City
| ^Vhc
| _bas, Vi
| village

|-
| Snowy Human City
| ^Vhca
| _bas, Vi
| village

|-
| Ruined Human City
| ^Vhcr
| _bas, Vi
| village

|-
| Hill Stone Village
| ^Vhh
| _bas, Vi
| village, rough

|-
| Snowy Hill Stone Village
| ^Vhha
| _bas, Vi
| village, frozen, rough

|-
| Ruined Hill Stone Village
| ^Vhhr
| _bas, Vi
| village, rough

|-
| Tropical Village
| ^Vht
| _bas, Vi
| village

|-
| Drake Village
| ^Vd
| _bas, Vi
| village

|-
| Cave Village
| ^Vu
| _bas, Vi
| village, cave

|-
| Dwarven Village
| ^Vud
| _bas, Vi
| village, cave

|-
| Hut
| ^Vc
| _bas, Vi
| village

|-
| Snowy Hut
| ^Vca
| _bas, Vi
| village, frozen

|-
| Log Cabin
| ^Vl
| _bas, Vi
| village

|-
| Snowy Log Cabin
| ^Vla
| _bas, Vi
| village, frozen

|-
| Igloo
| ^Vaa
| _bas, Vi
| village, frozen

|-
| Swamp Village
| ^Vhs
| _bas, Vi
| water, village

|-
| Aquatic Village
| Ww^Vm
| Ww
| water, village

|-
| Aquatic Village
| Ss^Vm
| Ss
| water, village

|-
| Village
| ^Vov
| _bas
| village, special

|-
| Encampment
| Ce
| Ch
| castle

|-
| Snowy Encampment
| Cea
| Ch
| castle, frozen

|-
| Orcish Castle
| Co
| Ch
| castle

|-
| Snowy Orcish Castle
| Coa
| Ch
| castle, frozen

|-
| Castle
| Ch
|
| castle

|-
| Snowy Human Castle
| Cha
| Ch, At
| castle, frozen

|-
| Elvish Castle
| Cv
| Ch
| castle

|-
| Dwarven Castle
| Cud
| Ch
| castle, cave

|-
| Ruined Human Castle
| Chr
| Ch
| castle

|-
| Sunken Human Ruin
| Chw
| Ch, Ww
| castle, water

|-
| Swamp Human Ruin
| Chs
| Ch, Ss
| castle, water

|-
| Desert Castle
| Cd
| Ch
| castle, desert

|-
| Ruined Desert Castle
| Cdr
| Ch
| castle, desert

|-
| Encampment Keep
| Ke
| Ch
| castle

|-
| Tall Encampment Keep
| Ket
| Ch
| castle

|-
| Snowy Encampment Keep
| Kea
| Ch
| castle, frozen

|-
| Orcish Keep
| Ko
| Ch
| castle

|-
| Snowy Orcish Keep
| Koa
| Ch
| castle, frozen

|-
| Keep
| Kh
| Ch
| castle

|-
| Snowy Human Castle Keep
| Kha
| Ch, At
| castle, frozen

|-
| Elven Castle Keep
| Kv
| Ch
| castle

|-
| Dwarven Castle Keep
| Kud
| Ch
| castle, cave

|-
| Ruined Human Castle Keep
| Khr
| Ch
| castle

|-
| Sunken Keep
| Khw
| Ch, Ww
| castle, water

|-
| Swamp Keep
| Khs
| Ch, Ss
| castle, water

|-
| Keep
| Kd
| Ch
| castle, desert

|-
| Keep
| Kdr
| Ch
| castle, desert

|-
| Castle
| ^Cov
| _bas
| castle, special

|-
| Keep
| ^Kov
| _bas
| castle, special

|-
| Wooden Bridge
| ^Bw|
| _bas, Gt
| bridge, water

|-
| Wooden Bridge
| ^Bw/
| _bas, Gt
| bridge, water
|-
| Wooden Bridge
| ^Bw\
| _bas, Gt
| bridge, water
|-
| Basic Stone Bridge
| ^Bsb|
| _bas, Gt
| bridge,water

|-
| Basic Stone Bridge
| ^Bsb\
| _bas, Gt
| bridge,water

|-
| Basic Stone Bridge
| ^Bsb/
| _bas, Gt
| bridge,water

|-
| Cave Chasm Bridge
| ^Bs|
| Uu,_bas
| bridge, cave

|-
| Cave Chasm Bridge
| ^Bs/
| Uu,_bas
| bridge, cave

|-
| Cave Chasm Bridge
| ^Bs\
| Uu,_bas
| bridge, cave

|-
| Off Map
| _off^_usr # wmllint: ignore
|
| special, obstacle

|-
| Experimental Fake Map Edge
| ^_fme # wmllint: ignore
|
| special, obstacle

|-
| Shroud
| _s # wmllint: ignore
|
| special

|-
| Fog
| _f # wmllint: ignore
|
| special

|-
| precated. Use Flower Overlay
| Ggf
| Gt
| flat

|-
| precated. Use 'Mv'
| Qv
| Qt
| rough, obstacle

|}

TerrainCodesWML

2011-03-13T18:48:42Z

SkeletonCrew: /* Terrain Table */ Removed the table and refer to the new page

{{WML Tags}}

Note: the old (1.2) terrain system is no longer documented here. If you have 1.2 maps you will need to convert them using [[Maintenance_tools|wmllint]].

== Terrain strings ==

The following rules hold for terrain strings. Note most of these rules are not validated since it would slow down Wesnoth; not following these rules might break Wesnoth.

* terrain strings are composed from one or more terrain codes of 2 to 4 characters each, separated by ^.
* terrain codes start with a capital letter and the following letters are lower case
* terrain strings can only contain letters, the symbols /|\ which are meant for directional items like bridges and the symbol ^
* the underscore is used as a leader for internal terrain codes
* the star '*' can be used for wildcards in some places where a terrain code is required
* the symbol ^ indicates that a terrain is created with layers, for example Gs^Fp means Forest(Fp) overlayer on Savanna(Gs).

Starting positions are defined by a number followed by 1 space and then the terrain string; this means that a starting position is no longer automatically a keep.

The letters Y,y,Z,z are reserved for UMC so any string containing any of these letters is a custom terrain. Other undefined terrain strings are reserved for future expansion within Wesnoth.

=== Terrain Table ===

The list of terrains can be found at [[TerrainCodeTableWML]]. Since most overlays can be combined with most bases the list is not complete.

== Adding terrains ==
When adding terrains make sure the following files are also checked:

data/multiplayer/factions/* contains favorite positions for the different factions, this is only used for the random map generator at the moment so it is not very important.

data/core/macros/abilities.cfg contains the definition of ''submerge'' and ''ambush'' so depending on the change these need to be updated.

== Decoding the Terrain Codes ==
The initial letters of each terrain code have a standard meaning, though some are not obvious.
* A = “Arctic” i.e. frozen
* B = “Bridge”
* C = “Castle”
* D = “Desert”
* E = "Embellishment"
* F = “Forest”
* G = “Grass”
* H = “Hills”
* I = "Interior" (possible future use)
* J = ''testing''
* K = “Keep”
* L
* M = “Mountains”
* N
* O
* P
* Q = "Un-walkable"
* R = “Road”
* S = “Swamp”
* T
* U = “Underground”
* V = “Village”
* W = “Water”
* X = "Impassable"
* Y = ''Reserved for UMC''
* Z = ''Reserved for UMC''
* _ = "special system stuff"

Additional letters are not always follow the same meaning, but are as consistent as possible.

* \, |, / = for indicating the direction of bridges
* a =
* b =
* c = "city"
* d = "dry or desert, deciduous"
* e = "encampment"
* f = "flowers, fall"
* g
* h = "human"
* i = "ice"
* j
* k
* l = "lava"
* m = "mixed"
* n
* o = "orc"
* p = "pine"
* q
* r
* s = "simple"
* t
* u = "underground"
* v = "elvish"
* w
* x = "chasm"
* y = ''Reserved for UMC''
* z = ''Reserved for UMC''

== See Also ==
* [[TerrainWML]]
* [[ReferenceWML]]

[[Category: WML Reference]]

TerrainCodeTableWML

2011-03-13T18:45:54Z

SkeletonCrew: Add initial version generated with terrain2wiki.py

{{AutogeneratedWML}}{| border="1"
!name
!string
!alias of
!editor group
|-
| Gray Deep Water
| Wog
| Wo
| water

|-
| Deep Water
| Wo
|
| water

|-
| Tropical Deep Water
| Wot
| Wo
| water

|-
| Gray Shallow Water
| Wwg
| Ww
| water

|-
| Shallow Water
| Ww
|
| water

|-
| Tropical Shallow Water
| Wwt
| Ww
| water

|-
| Ford
| Wwf
| Gt, Ww
| water

|-
| Coastal Reef
| Wwr
|
| water

|-
| Swamp
| Ss
|
| water

|-
| Muddy Quagmire
| Sm
| Ss
| water

|-
| Green Grass
| Gg
| Gt
| flat

|-
| Semi-dry Grass
| Gs
| Gt
| flat

|-
| Dry Grass
| Gd
| Gt
| flat

|-
| Leaf Litter
| Gll
| Gt
| flat

|-
| Dark Dirt
| Rb
| Gt
| flat

|-
| Regular Dirt
| Re
| Gt
| flat

|-
| Dry Dirt
| Rd
| Gt
| desert, flat

|-
| Regular Cobbles
| Rr
| Gt
| flat

|-
| Clean Gray Cobbles
| Rrc
| Gt
| flat

|-
| Overgrown Cobbles
| Rp
| Gt
| flat

|-
| Ice
| Ai
| At
| frozen

|-
| Snow
| Aa
| At
| frozen

|-
| Desert Sands
| Dd
| Ds
| desert

|-
| Sand
| Ds
|
| desert

|-
| Oasis
| Dd^Do
| Ds
| desert, forest

|-
| Rubble
| ^Dr
| _bas, Hh
| desert, rough

|-
| Crater
| Dd^Dc
| Ds
| desert

|-
| Mixed Flowers
| ^Efm
| _bas
| embellishments

|-
| Farmland
| ^Gvs
| _bas
| embellishments

|-
| Stones
| ^Es
| _bas
| embellishments

|-
| Small Mushrooms
| ^Em
| _bas
| embellishments

|-
| Mushroom Farm
| ^Emf
| _bas
| embellishments,cave

|-
| Desert Plants
| ^Edp
| _bas
| embellishments, desert

|-
| Desert Plants without Bones
| ^Edpp
| _bas
| embellishments, desert

|-
| Windmill
| ^Wm
| _bas
| embellishments

|-
| Fence
| ^Eff
| _bas
| embellishments

|-
| Stones with Sand Drifts
| ^Esd
| _bas
| embellishments, desert

|-
| Water Lilies
| ^Ewl
| _bas
| water,embellishments

|-
| Flowering Water Lilies
| ^Ewf
| _bas
| water,embellishments

|-
| Great Tree
| ^Fet
| ^Fp
| forest

|-
| Tropical Forest
| ^Ft
| ^Fp
| forest

|-
| Forest
| ^Fp
|
| forest

|-
| Snowy Pine Forest
| ^Fpa
| At,^Fp
| frozen, forest

|-
| Summer Deciduous Forest
| ^Fds
| ^Fp
| forest

|-
| Fall Deciduous Forest
| ^Fdf
| ^Fp
| forest

|-
| Winter Deciduous Forest
| ^Fdw
| ^Fp
| forest

|-
| Snowy Deciduous Forest
| ^Fda
| At,^Fp
| frozen, forest

|-
| Summer Mixed Forest
| ^Fms
| ^Fp
| forest

|-
| Fall Mixed Forest
| ^Fmf
| ^Fp
| forest

|-
| Winter Mixed Forest
| ^Fmw
| ^Fp
| forest

|-
| Snowy Mixed Forest
| ^Fma
| At,^Fp
| frozen, forest

|-
| Hills
| Hh
|
| rough

|-
| Dry Hills
| Hhd
| Hh
| rough

|-
| Dunes
| Hd
| Ds, Hh
| desert, rough

|-
| Snow Hills
| Ha
| At, Hh
| frozen, rough

|-
| Mountains
| Mm
|
| rough

|-
| Dry Mountains
| Md
| Mm
| rough, desert

|-
| Snowy Mountains
| Ms
| At, Mm
| rough, frozen

|-
| Forested Hills
| Hh^Fp
| Hh,^Fp
| forest, rough

|-
| Forested Snow Hills
| Ha^Fpa
| Ha,^Fp
| forest, rough, frozen

|-
| Summer Deciduous Forested Hills
| Hh^Fds
| Hh,^Fp
| forest, rough

|-
| Fall Deciduous Forested Hills
| Hhd^Fdf
| Hh,^Fp
| forest, rough

|-
| Winter Deciduous Forested Hills
| Hhd^Fdw
| Hh,^Fp
| forest, rough

|-
| Snowy Deciduous Forested Hills
| Ha^Fda
| Ha,^Fp
| frozen, forest, rough

|-
| Summer Mixed Forested Hills
| Hh^Fms
| Hh,^Fp
| forest, rough

|-
| Fall Mixed Forested Hills
| Hhd^Fmf
| Hh,^Fp
| forest, rough

|-
| Winter Mixed Forested Hills
| Hhd^Fmw
| Hh,^Fp
| forest, rough

|-
| Snowy Mixed Forested Hills
| Ha^Fma
| Ha,^Fp
| frozen, forest, rough

|-
| Basic Wooden Floor
| Iwr
| Gt
| flat

|-
| Lit
| ^Ii
| _bas
| cave

|-
| Cave
| Uu
|
| cave

|-
| Earthy Cave Floor
| Uue
| Uu
| cave

|-
| Dark Flagstones
| Urb
| Gt

| cave
|-
| Cave Path
| Ur
| Gt
| cave

|-
| Mushroom Grove
| ^Uf
|
| cave, forest

|-
| Lit Mushroom Grove
| ^Ufi
| ^Uf
| cave

|-
| Rockbound Cave
| Uh
| Uu, Hh
| cave, rough

|-
| Mine Rail
| ^Br|
| _bas
| cave

|-
| Mine Rail
| ^Br/
| _bas
| cave

|-
| Mine Rail
| ^Br\
| _bas
| cave

|-
| Regular Chasm
| Qxu
| Qt
| cave, obstacle

|-
| Earthy Chasm
| Qxe
| Qt
| cave, obstacle

|-
| Ethereal Abyss
| Qxua
| Qt
| obstacle

|-
| Lava Chasm
| Ql
| Qt
| cave, obstacle

|-
| Lava
| Qlf
| Qt
| cave, obstacle

|-
| Volcano
| Mv
| Qt
| rough, obstacle

|-
| Regular Impassable Mountains
| Mm^Xm
| Xt
| rough,obstacle

|-
| Desert Impassable Mountains
| Md^Xm
| Xt
| rough,obstacle,desert

|-
| Snowy Impassable Mountains
| Ms^Xm
| Xt
| rough,obstacle,frozen

|-
| Natural Cave Wall
| Xu
| Xt
| cave,obstacle

|-
| Hewn Cave Wall
| Xuc
| Xt
| cave,obstacle

|-
| Natural Earthy Cave Wall
| Xue
| Xt
| cave,obstacle

|-
| Reinforced Earthy Cave Wall
| Xuce
| Xt
| cave,obstacle

|-
| Stone Wall
| Xos
| Xt
| cave,obstacle

|-
| Lit Stone Wall
| Xol
| Xt
| cave,obstacle

|-
| Impassable Overlay
| ^Xo
| _bas,Xt
| special

|-
| Void
| Xv
| Xt
| obstacle, special

|-
| Adobe Village
| ^Vda
| _bas, Vi
| village, desert

|-
| Desert Tent Village
| ^Vdt
| _bas, Vi
| village, desert

|-
| Tent Village
| ^Vct
| _bas, Vi
| village

|-
| Orcish Village
| ^Vo
| _bas, Vi
| village

|-
| Snowy Orcish Village
| ^Voa
| _bas, Vi
| village, frozen

|-
| Snowy Elven Village
| ^Vea
| _bas, Vi
| village, frozen

|-
| Elven Village
| ^Ve
| _bas, Vi
| village

|-
| Cottage
| ^Vh
| _bas, Vi
| village

|-
| Snowy Cottage
| ^Vha
| _bas, Vi
| village, frozen

|-
| Ruined Cottage
| ^Vhr
| _bas, Vi
| village

|-
| Human City
| ^Vhc
| _bas, Vi
| village

|-
| Snowy Human City
| ^Vhca
| _bas, Vi
| village

|-
| Ruined Human City
| ^Vhcr
| _bas, Vi
| village

|-
| Hill Stone Village
| ^Vhh
| _bas, Vi
| village, rough

|-
| Snowy Hill Stone Village
| ^Vhha
| _bas, Vi
| village, frozen, rough

|-
| Ruined Hill Stone Village
| ^Vhhr
| _bas, Vi
| village, rough

|-
| Tropical Village
| ^Vht
| _bas, Vi
| village

|-
| Drake Village
| ^Vd
| _bas, Vi
| village

|-
| Cave Village
| ^Vu
| _bas, Vi
| village, cave

|-
| Dwarven Village
| ^Vud
| _bas, Vi
| village, cave

|-
| Hut
| ^Vc
| _bas, Vi
| village

|-
| Snowy Hut
| ^Vca
| _bas, Vi
| village, frozen

|-
| Log Cabin
| ^Vl
| _bas, Vi
| village

|-
| Snowy Log Cabin
| ^Vla
| _bas, Vi
| village, frozen

|-
| Swamp Village
| ^Vhs
| _bas, Vi
| water, village

|-
| Aquatic Village
| Ww^Vm
| Ww
| water, village

|-
| Aquatic Village
| Ss^Vm
| Ss
| water, village

|-
| Village
| ^Vov
| _bas
| village, special

|-
| Encampment
| Ce
| Ch
| castle

|-
| Snowy Encampment
| Cea
| Ch
| castle, frozen

|-
| Orcish Castle
| Co
| Ch
| castle

|-
| Snowy Orcish Castle
| Coa
| Ch
| castle, frozen

|-
| Castle
| Ch
|
| castle

|-
| Snowy Human Castle
| Cha
| Ch, At
| castle, frozen

|-
| Elvish Castle
| Cv
| Ch
| castle

|-
| Dwarven Castle
| Cud
| Ch
| castle, cave

|-
| Ruined Human Castle
| Chr
| Ch
| castle

|-
| Sunken Human Ruin
| Chw
| Ch, Ww
| castle, water

|-
| Swamp Human Ruin
| Chs
| Ch, Ss
| castle, water

|-
| Desert Castle
| Cd
| Ch
| castle, desert

|-
| Ruined Desert Castle
| Cdr
| Ch
| castle, desert

|-
| Encampment Keep
| Ke
| Ch
| castle

|-
| Tall Encampment Keep
| Ket
| Ch
| castle

|-
| Snowy Encampment Keep
| Kea
| Ch
| castle, frozen

|-
| Orcish Keep
| Ko
| Ch
| castle

|-
| Snowy Orcish Keep
| Koa
| Ch
| castle, frozen

|-
| Keep
| Kh
| Ch
| castle

|-
| Snowy Human Castle Keep
| Kha
| Ch, At
| castle, frozen

|-
| Elven Castle Keep
| Kv
| Ch
| castle

|-
| Dwarven Castle Keep
| Kud
| Ch
| castle, cave

|-
| Ruined Human Castle Keep
| Khr
| Ch
| castle

|-
| Sunken Keep
| Khw
| Ch, Ww
| castle, water

|-
| Swamp Keep
| Khs
| Ch, Ss
| castle, water

|-
| Keep
| Kd
| Ch
| castle, desert

|-
| Keep
| Kdr
| Ch
| castle, desert

|-
| Castle
| ^Cov
| _bas
| castle, special

|-
| Keep
| ^Kov
| _bas
| castle, special

|-
| Wooden Bridge
| ^Bw|
| _bas, Gt
| bridge, water

|-
| Wooden Bridge
| ^Bw/
| _bas, Gt
| bridge, water
|-
| Wooden Bridge
| ^Bw\
| _bas, Gt
| bridge, water
|-
| Basic Stone Bridge
| ^Bsb|
| _bas, Gt
| bridge,water

|-
| Basic Stone Bridge
| ^Bsb\
| _bas, Gt
| bridge,water

|-
| Basic Stone Bridge
| ^Bsb/
| _bas, Gt
| bridge,water

|-
| Cave Chasm Bridge
| ^Bs|
| Uu,_bas
| bridge, cave

|-
| Cave Chasm Bridge
| ^Bs/
| Uu,_bas
| bridge, cave

|-
| Cave Chasm Bridge
| ^Bs\
| Uu,_bas
| bridge, cave

|-
| Off Map
| _off^_usr # wmllint: ignore
|
| special, obstacle

|-
| Experimental Fake Map Edge
| ^_fme # wmllint: ignore
|
| special, obstacle

|-
| Shroud
| _s # wmllint: ignore
|
| special

|-
| Fog
| _f # wmllint: ignore
|
| special

|-
| precated. Use Flower Overlay
| Ggf
| Gt
| flat

|-
| precated. Use 'Mv'
| Qv
| Qt
| rough, obstacle

|}

SoC Information for Google

2011-03-10T19:17:18Z

SkeletonCrew: /* SoC Information for Google */ few minor tweaks

{{Template:SoC2011}}

== SoC Information for Google ==
This is the information that we submit to google as Application in Summer of Code (current status: 2011). The submitter automatically becomes primary Admin. Most entries are mandatory and have to be filled out before the application can be submitted.

==== Organization Name: ====
Battle for Wesnoth

==== Description: ====
''Battle for Wesnoth'', or simply ''Wesnoth'', is a free, turn-based strategy game with role-playing elements that was designed in June 2003 by David White (Sirp).

Although the core rules are fairly simple and meant to be easily learned[1], they provide interesting gameplay and rich tactical options. A major strength of the project is the Wesnoth Markup Language (WML) for writing scenarios. Programming skills are not required to compose with it, and a large WML-modding community has generated a great deal of user-maintained content. We polish the best of this content and lift it into our official release tree.

The first stable release (1.0) was on October 2, 2005, and the latest stable release (1.8) happened in april 2010. Version 1.8 is a major stable checkpoint, and 1.10 is not anticipated before the end of 2011. The currentdevelopment cycle (1.9, leading to 1.10) will premier significant changes in gameplay, UI, and development tools, with many new concepts being introduced. That makes this year probably one of the best years for a SoC student to join, since the open-ended 1.9 will mean much more space to develop novel ideas.

''Wesnoth'' is one of the most successful open-source game projects in existence, with an exceptionally large developer base and user community:

* According to Ohloh, a site that collects activity statistics on open-source projects, the ''Wesnoth'' development effort is in the top 2% of largest and most active projects.
* We support two multiplayer game servers (stable and development) with a usual minimum load of more than a hundred players.
* More than two thousands downloads a day
* 4.5 million downloads via SourceForge; many more via various mirrors of Linux distributions
* Best rated game at the Linux Game Tome[2]
* Game of the year 2007, 2008, 2009, and 2010 at LinuxQuestions.org[3][4]
* In general, ''Wesnoth'' tends to show up in the first or second position whenever anyone compiles a list of top open-source games.

''Wesnoth'''s most notable features include:

* A mature project with continuing active development and frequent improvements
* High quality artwork: both original graphics and music
* Well-balanced by a tireless team of playtesters
* Fun, unique gameplay
* Even after six years of development and with a very solid, fun product already created, there are still plenty of new developers; the number of commits to Subversion is still increasing
* Strong support of internationalization with many supported languages, thus experience in working with non-native English speakers. In fact, more than half of our developers are not native English speakers.

[1] http://www.wesnoth.org/wiki/WesnothPhilosophy

[2] http://www.happypenguin.org/list?sort=avg_rating

[3] http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/

[4] http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/

==== Home page: ====
http://www.wesnoth.org/

==== Main Organization License: ====
GNU General Public License version 2.0 (GPLv2) [Dropdown box answer!]

==== Why is your organization applying to participate in GSoC 2011? What do you hope to gain by participating? ====
Most of our developers have particular areas of interest in which they work. Though they are efficient in their areas, there are other, presently uncovered, areas of the code with a need for improvements but a high barrier to entry for casual contributors.

Our previous SoC experience shows that a motivated, full-time, student can be brought up to date in any area fairly quickly.

By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart some areas of the project that are currently lagging behind.

Moreover, our previous experiences has shown us that SoC developers tend to stay after the end of the Summer of Code and become valuable members of our community. This has been a win in all directions and we want it to happen again.

==== If accepted, would this be your first year participating in GSoC? ====
No

==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. ====
2008 results:
Wesnoth participated in GSoC 2008 with four students. Out of these, two were great successes (that is they became full-fledge developers before the actual start of GSoC), did huge improvement during GSoC (A new recruitment algorithm for the AI and the basic structure for a new map editor, the student finished this work after the summer), and are still active developers in the Wesnoth community.

Of the two other, one of them was very active for the first half of GSoC and provided some useful infrastructure for AI development that we used as base in GSoC 2009, but was much less active and didn't reach expectations for the second half of GSoC. The lesson we learned is that great students should be left on their own, that's the best way to have them work, but average students should be monitored much more closely than we did. If things seems to start to go wrong, it's important to react very quick, to meet with other mentors and get things back on track early.

Timezone problems were also a serious barrier for student/mentor communication, and we will take that more into account when pairing mentors and students

For our other students, multiple problems collectively led to failure
* We should enforce IRC communication, E-mail is a barrier. This applies both for students and mentors. Both should be on IRC several hours a day, with overlapping hours.
* We should be more strict about mid-term evaluation. If the student is slightly lacking at mid-term we should give a clear message that he needs to get back on track.

2009 results:
In 2009 we mentored 6 students as part of Summer of Code. Out of these 5 projects were a success. From those 5 developers 3 are still part of our core development group and still maintain and improve the work they submitted as part of Summer of Code. One of the students even became the "head" of our AI development department and mentored a student this year. For a summary of the 2009 results have a look at [1].

Sadly one student was not able to continue his work past midterm due to his computer failing completely as well as personal problems that we won't delve into further here. It was not a salvageable situation.

2010 results:
In 2010 we mentored 4 students as part of Summer of Code, all the projects were a success. from those 4 developers, 1 is still part of our code development team and maintains the work he has done as part of Summer of Code.

[1] http://forums.wesnoth.org/viewtopic.php?f=5&t=26955

==== If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006. ====
2008: 2/4
2009: 5/6
2010: 4/4

==== What is the URL for your ideas page? ====
http://wiki.wesnoth.org/SummerOfCodeIdeas

==== What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2011. If your organization uses more than one list, please make sure to include a description of the list so students know which to use. ====
The main development mailing list is "wesnoth-dev@gna.org". Our main means of communications is our IRC channel on freenode. If you have questions you should ask them in #wesnoth-dev on irc.freenode.net and wait for a reply (might take some hours!). The Wesnoth related channels are logged in public and the logs tend to be read by developers.

==== What is the main IRC channel for your organization? ====
#wesnoth-dev on irc.freenode.net

==== Does your organization have an application template you would like to see students use? If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2011 site. ====
We plan mainly to meet potential students through our IRC channel, but the following questions are Wesnoth specific and are worth pondering for any student, even if we don't need a formal answer. So please beside just answering these questions consider visiting us in IRC: #wesnoth-dev on irc.freenode.net. This is where most of our work takes place and participating in IRC is mandatory for GSoC students participating with Wesnoth. Our experience is that this is the easiest way to communicate and solve problems that come up.

If you want to participate in GSoC as a student please copy http://wiki.wesnoth.org/SoC2011_Template_of_Student_page to a new page and fill it with the answers to the following questions

Again, participating on IRC will be highly considered, you should not hesitate to ask any questions there, including how to fill a good proposal. We highly value your capacity to communicate and work in a team, so help other students, actively ask for proposal criticism, this can only help your proposal

1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

1.4) Why do you want to participate in summer of code?

1.5) What are you studying, subject, level and school?

1.6) What country are you from, at what time are you most likely to be able to join IRC?

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

2) Experience

2.1) What programs/software have you worked on before?

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or gameplay?

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

3.2) What spoken languages are you fluent in?

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

3.6) Are you good at sorting useful criticisms from useless ones?

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

4.2) If you have invented your own project, please describe the project and the scope.

4.3) Why did you choose this project?

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

4.5) Include as much technical detail about your implementation as you can

4.6) What do you expect to gain from this project?

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
* Subversion (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* Python (optional, mainly used for tools)
* build environments (eg cmake/autotools/scons)
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)

5.2) Which tools do you normally use for development? Why do you use them?

5.3) What programming languages are you fluent in?

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

In general please try to be as verbose as possible in your answers and feel free to elaborate.

==== What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible. ====
Our first criterion was that all the people had to be volunteers. According to other open source projects and our experience from the last two years, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.

Boucman is one of the oldest active developers around. He has rewritten the whole animation engine and made it an easily pluggable system allowing artists to easily specify exactly how they want the units to appear. He also started many community oriented projects like the Art Contribution[1] section of the wiki (now deprecated) and the WML Reference Manual[2]. He is responsible for dispatching and sorting the patches at http://patches.wesnoth.org that has created the new developer process we currently use. Boucman was a mentor in 2008, 2009 and 2010.

Iurii Chernyi (Crab) has joined the team in 2009, taking part in Google Summer of Code 2009, and staying with the project as a developer after successful completion of GSoC. He's an expert on all aspects of current Wesnoth AI codebase (having fully reorganized it as part of GSoC 2009), and has fixed numerous bugs all over Wesnoth. He was a GSoC mentor and a GCI mentor and administrator in 2010. He is experienced in teaching other people, in areas like programming languages and math.

Fendrin has some skills on both ends of the Wesnoth world, knowing parts of the c++ engine and how to use the Wesnoth markup language. He is the coder and maintainer of Wesnoth's first multiplayer campaign that is hosted in the mainline repository. His experience as a content developer ensures that there is an eye kept on the usability of those new features which are accessible to content designers. Fendrin was a mentor in 2010.

Mordante is one of the most active developers on our IRC channel. Not only has he done preliminary studies and coding in multiple areas that are candidates for Summer of Code ideas, he also is one of the coders with the best overview of the Wesnoth code. A large part of his work involves refactoring and polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base. He is currently completing a rewrite of the Wesnoth GUI library, making all windows configurable through WML. This should make it easier to use Wesnoth on different resolutions, from small handheld devices to large 30 inch screens. Mordante was a mentor in 2008, 2009 and 2010.

All other developers listed in the ideas page are the leading capacities we do have for the respecting areas. Have a look at our list of "people who to contact" [3] for an easy reference. In general all our developers will mentor all students. That is, questions should just be asked in our IRC channel, where basically every developer who has an idea can and will directly answer.

When choosing the mentors, we have kept in mind that most developers can answer most technical questions, and we have chosen people that are well known for interacting with new-comers/external developers and can provide general guidance and design advice, more than people with specific technical knowledge.

[1] http://wiki.wesnoth.org/UnsortedContrib

[2] http://wiki.wesnoth.org/ReferenceWML

[3] http://wiki.wesnoth.org/SoC_People_to_bug_on_IRC

==== What is your plan for dealing with disappearing students? ====
The first thing to do is to avoid this situation altogether.

Wesnoth is a game, and as such has lots of developers that are not coders. In particular, artists are well known in the Wesnoth community for being very sensitive about criticism and our community is used to people being sensitive to critics.

We will try to choose students that accept criticism and are able to filter constructive criticism from useless one. The Wesnoth developer community is used to judging people according to these criteria and the special title we are going to give to applicants will allow us to easily spot any such problems and discuss them before they grow out of control.

If a student disappears, their mentor will be in charge of recontacting the student to see what is going wrong (available time, tension with other developers, with members of the community etc...). Depending on the actual problem, the mentor and the student will have to agree on possible ways to defuse the problem.

If a student disappears completely and there is no way to get back to them, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have SVN write access, so most of the work will be committed either to trunk or to a specific branch) and find a core developer to take on the job. This will probably be slower and less effective for the project, but it's the best we can do.

==== What is your plan for dealing with disappearing mentors? ====
All our mentors are long time developers that volunteered for the job, so we don't expect that to happen. We observed in during the last years the amount of time required to mentor, and our mentors accepted the job knowing the amount of work it involved. All of this years mentors mentored last year as well.

However, should it happen, we would continue to mentor as a developer community the student until we find a new "official" mentor to take on the job.

==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====
Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two (non trival) patches... you're in". With other words, anybody that is able to get two non-trivial patches applied is offered commit privileges.
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our EasyCoding pages [1] (these projects are usually a couple of hours long and hve been chosen to provide easy access to the respective area of code). This year, we also have added some simple coding tasks directly related to our GSoC ideas to be able to test students more specifically on their future project

Usually, patches go back and forth a couple of times, to make sure that all secondary things are in place (indenting, coding style, modified buildfiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to keep our project alive.

If the student is proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

In 2008, 2009 and 2010 all students that were accepted (and a couple more) managed to have commit access before the start of the coding phase. We consider that this policy was successful and we plan to keep it this year.

We also plan to give a special forum title to any students. This will allow all forum members to tell them apart from normal users and give them read/write access to the developer only forums. This will also allow us to quickly spot any problem they might have interacting with the player community. We have a very mature developer community, but our player community is made of all sort of people of all age and education, and it can sometimes be rough.

Last, our experience from previous years is that students that participate in the community during the evaluation period will stay active in the community after that period. In previous years this has been a discriminating criterias for students of similar level, and overall we never had problems of students working "behind a black wall." Our selection process tend to favor students who participate, and participation hasn't been a problem so far.

[1] http://wiki.wesnoth.org/EasyCoding

==== If you are a small or new organization applying to GSoC, please list a larger, established GSoC organization or a Googler that can vouch for you here. ====

==== If you are a large organization who is vouching for a small organization applying to GSoC for their first time this year, please list their name and why you think they'd be good candidates for GSoC here: ====
* Darktable:
Darktable (see http://darktable.sourceforge.net/ and https://sourceforge.net/apps/trac/darktable/wiki/GSOC) is an open source raw development tool.

There are currently no major open source raw development tools. Multiple tools cover the need (ufraw, rawtherapee etc...) but most of them are targeting technical users with interest in photography or signal processing experts rather than "normal" photographer.

Darktable has a very good UI designed around what most photographers expects. It is also a project which is at this interesting stage where there is a solid infrastructure and it needs developer to do the fun part of adding new feature. This is the stage of a project which is the most interesting for developers to join.

The Darktable development community is rather small (3 active developers plus occasional contributors). It could use the extra manpower but is large enough to mentor a student into a core developer pretty fast.

Chances of a student finding it interesting are high, chances of the student bringing major contributions to the project are very high

One of the experienced wesnoth mentor (boucman) is an active member of the Darktable community and has been spearheading the GSoC effort for that community and will offer advice and participation for the new mentors in that community. Wesnoth has had a dedicated IRC channel for mentor discussion which could be used by smaller projects for advice if the need arise

* Unknown Horizons:
Unknown Horizons (http://www.unknown-horizons.org/) is a 2D realtime strategy simulation with an emphasis on economy and city building.

This is a smaller open source game project with a really dedicated core team of developers. During our talks with the dev who wants to work as admin it was easy to see that they do think about what they do and got some well working infrastructure. Even though the team is rather small at the moment, they are well suited to handle some students and the project has a proven record of being able to actually release something and continue working on the code. Beside their abilities it is always good to support open source gaming, especially when it comes to rather underrepresented areas like real time strategy games.

==== Anything else you'd like to tell us? ====
There is nothing more to say.

==== Backup Admin (Link ID): ====
noy

==== Admin Agreement: ====
(some terms of service by Google that have to be agreed upon)

SoC Ideas Multiplayer Improvements 2011

2011-03-09T16:28:56Z

SkeletonCrew: minor grammer and language changes

{{SoC2011Idea}}

=Description=
<h2>Reengineer Wesnoth's multiplayer engine</h2>

More info at [[SoC_Ideas_Multiplayer_Improvements_2011]]

Wesnoth includes a lot of multiplayer content, like 'standard' scenarios, custom scenarios and multiplayer campaigns. However, when creating a multiplayer game, the player's options are highly limited - for example, it is not possible to select the difficulty level before starting the scenario, and it is not possible to allow the scenario to set what 'variables' can be customized by players before game is started (there's only global 'use map settings' flag and some control over sides). We want to reengineer the architecture of Wesnoth's multiplayer engine to allow it to support those things.

{{#dpl:
|resultsheader=''There are %PAGES% submitted student proposals for this idea''
|oneresultheader=''There is 1 submitted student proposal for this idea''
|suppresserrors=true
|noresultsheader=''There are no submitted student proposals for this idea''
|category=Summer of Code 2011 Student Page&SoC Ideas Multiplayer Improvements
|notcategory=SoC 2011 Not Submitted To Google
|include=#Description
|mode=userformat
|format=,, See [[%PAGE%|%TITLE%]] for more information. ,
}}

=Additional Information=
== Difficulty levels in MP ==
Wesnoth includes a lot of text data config files which need to be 'parsed' before game starts. Difficulty needs to be known at the time we parse those config files. Currently, we parse those files before entering the multiplayer lobby. As a consequence, we cannot select difficulty in multiplayer game (the data's already parsed at the point when the game is created). Note that parsing takes a lot of time, so, if we do it while already connected to MP server, we need to add workarounds to ensure it doesn't think the client disconnected.

== Game creation screen ==
We want the multiplayer game creation screen to be different and better. We think that we need different screens for normal MP scenarios, 'custom' MP scenarios and for MP campaigns.

== Unification of multiplayer and singleplayer in the engine==
A really long-term goal would be to reduce the complexity of the codebase by merging SP and MP (making SP a special case of MP and allow seamless transition between both). There is a number of steps which could be taken to gradually move closer to this goal.

== Under the hood ==
Wesnoth uses a pre-processor to organise its file hierarchy and to make use of macros.
This system is used to load only a certain subset of all available WML code depending on the current needs.

A freshly started Wesnoth instance does neither know about the inners of single player campaigns nor multiplayer content.
The player is able to choose between the mainline campaigns before the wml tree gets re-parsed because the [campaign] tag hosted in the campaign's _main.cfg contains all needed information and it's parsed from game start.

But the engine does only read the _main.cfg when the whole directory was included by a pre-processor directive.
If you allow me to show you some wml code you will discover that the rest of the campaign is guarded by a pre-processor symbol.

From the _main.cfg of "Heir To The Throne":
.
.
.
[campaign]
id=Heir_To_The_Throne
.
.
.
define=CAMPAIGN_HEIR_TO_THE_THRONE
extra_defines=SOMETHING, ANYTHING # inserted as example
.
.
.
[/campaign]
.
.
.
#ifdef CAMPAIGN_HEIR_TO_THE_THRONE
[binary_path]
path=data/campaigns/Heir_To_The_Throne
[/binary_path]
[+units]
{campaigns/Heir_To_The_Throne/units}
[/units]

{campaigns/Heir_To_The_Throne/utils}
{campaigns/Heir_To_The_Throne/scenarios}
#endif
.
.
.
If the player selects the campaign he will be asked for the difficult level of the campaign.
After that the whole wmltree while be re-parsed, this time with the additional defines:
CAMPAIGN_HEIR_TO_THE_THRONE
one of EASY NORMAL HARD
SOMETHING
ANYTHING

=Whom to ask about this=
Ask Crab_ and/or fendrin on #wesnoth-dev

=Possible pre-gsoc tasks=

* Talk with devs, users, and MP devs about UI design of MP creation screens and show some prototypes of game creation screens for MP campaigns, and custom MP scenarios

* Hack in a way to select difficulty before MP scenario start (doesn't need to be done cleanly, can be a prototype hack)

* Add a new attribute to game creation screen, to allow each player to select a number from 1 to 100 and make it available to WML code as a variable after scenario starts. Bonus points if you allow host to see the variable in the game creation screen and allow him to change it and lock it down for any particular player.

* write or download a small MP campaign and report on any MP campaign support bugs that you find.

* implement a lobby command to make the player who issued that command host and start a game with specified parameters, bypassing side selection screen.

* Make yourself familiar with the multiplayer port of the "Legend of Wesmere" campaign. Try to understand why and how the difficult setting is handled in its case.

SoC Ideas LuaAI 2011

2011-03-09T16:24:25Z

SkeletonCrew: Fixed capitalization

{{Template:SoC2011Idea}}

=Description=
<h2>Extend Wesnoth's Lua AI support and improve Wesnoth's AI</h2>

More info at [[SoC_Ideas_LuaAI_2011]]

It is very important for Wesnoth to have a way of scripting AI without modifying the c++ source code. Some time ago, it was possible to use Python to code AIs, but it was removed due to security issues. Now, we have added Lua as a new way to script AI. The core capabilities were already added, but we need to integrate Lua AI scripts better.

Wesnoth AI consists of different components. Each component is a c++ object, which provides an interface to allow the ai to delegate part of the turn sequence to that c++ object. But, that c++ object can be a proxy for code written in different language, such as formula_ai or lua. So, we have a lua engine - a c++ class which is responsible with creating c++ proxies for lua code snippets. This lua engine must provide access to all the information that the c++ AI knows - caches like 'attacks' and 'possible moves', values of aspects such as 'aggression' and 'caution', etc. So, there's a large number of AI support functions which we need to expose to lua code.

{{#dpl:
|resultsheader=''There are %PAGES% submitted student proposals for this idea''
|oneresultheader=''There is 1 submitted student proposal for this idea''
|suppresserrors=true
|noresultsheader=''There are no submitted student proposals for this idea''
|category=Summer of Code 2011 Student Page&SoC Ideas Lua AI
|notcategory=SoC 2011 Not Submitted To Google
|include=#Description
|mode=userformat
|format=,, See [[%PAGE%|%TITLE%]] for more information. ,
}}

=Implementation plan=
To quote from Alpha Centauri, "Technological advance is an inherently iterative process. One does not simply take sand from the beach and produce a Dataprobe. We use crude tools to fashion better tools, and then our better tools to fashion more precise tools, and so on. Each minor refinement is a step in the process, and all of the steps must be taken. ".
* So, we firstly want to expose existing c++ things to lua.
* Then, we want to build a lua-based 'wesnoth lua ai standard library', a library of functions useful to an ai developer.
* Then, we want to build a library of high-level functions which will be directly usable by scenario developer, with the level of complexity like 'drop this 1-line macro here, set this unit variable there, and voila - the unit is now controlled by lua ai according to your wishes'
* example of such behavior are 'patrol', 'retreat', and 'guard' behaviors
* then, we want to improve the ai directly, areas like recruiting with multiple leaders, actually ''defending'' something, handling concepts like leadership,skirmish, illuminate, and other, even, created-from-WML, concepts
* then, we want to make sure that multiple ais can coordinate between themselves, and stick to a certain strategy in battle,as determined by situation and whims of scenario creator

=Useful links=

* [[Customizing_AI_in_Wesnoth_1.8]]
* [[AI_Module]]
* [[LuaAI]]
* [[LuaWML]]

=Definition of Done=
All information that is possible to use in c++ AI, is possible to use in Lua AI with relatively same level of complexity for AI author.
=Whom to ask about this=
Ask Crab_ on #wesnoth-dev

=Possible pre-gsoc tasks=
We want to make it easy to write Lua AI. The best way to ensure that is to try to write some AI components, and see what's easy, what's hard, and what's missing. So, here are a few things that can be done to get you started and to allow to code some useful lua/c++ code which can be included in wesnoth lua ai standard library.

* Write the AI which can complete Scenario 1 of the '''Heir to the Throne''' campaign on easy difficulty.
* Write the AI which can complete Scenario 1 of '''The Hammer of Thursagan''' campaign on easy difficulty.
* Write a recruitment procedure for the AI which uses with multiple leaders intelligently
* Write a system to attach 'behavior instructions written in lua' to specific units
* Write a patrol formula in Lua
* Write a basic attack routine which allows to inject a Lua 'rate attack combination' function into it.
* Re-implement useful formula ai functions in lua.

SoC Information for Google

2011-03-08T21:26:33Z

SkeletonCrew: change category to GSoC 2011

{{Template:SoC2011}}

== SoC Information for Google ==
This is the info that we submit to google as Application in Summer of Code (current status: 2010). The submitter automatically becomes primary Admin. Most entries are mandatory and have to be filled out before the application can be submitted.

==== Organization Name: ====
Battle for Wesnoth

==== Description: ====
''Battle for Wesnoth'', or simply ''Wesnoth'', is a free, turn-based strategy game with role-playing elements that was designed in June 2003 by David White (Sirp).

Although the core rules are fairly simple and meant to be easily learned[1], they provide interesting gameplay and rich tactical options. A major strength of the project is the Wesnoth Markup Language (WML) for writing scenarios. Programming skills are not required to compose with it, and a large WML-modding community has generated a great deal of user-maintained content. We polish the best of this content and lift it into our official release tree.

The first stable release (1.0) was on October 2, 2005, and the latest stable release (1.8) is anticipated in the next few weeks. Version 1.8 is intended to be a major stable checkpoint. We expect the following development cycle (1.9, leading to 1.10) to premier significant changes in gameplay, UI, and development tools, with many new concepts being introduced. That makes this year probably one of the best years for a SoC student to join, since the open-ended 1.9 will mean much more space to develop novel ideas

''Wesnoth'' is one of the most successful open-source game projects in existence, with an exceptionally large developer base and user community:

* According to Ohloh, a site that collects activity statistics on open-source projects, the ''Wesnoth'' development effort is in the top 2% of largest and most active projects.
* We support two multiplayer game servers (stable and development) with a usual minimum load of more than a hundred players
* More than two thousands downloads a day
* 4.5 million downloads via SourceForge; many more via various mirrors of Linux distributions
* Best rated game at the Linux Game Tome[2]
* Game of the year 2007, 2008, and 2009, 2010 at LinuxQuestions.org[3][4]
* In general, ''Wesnoth'' tends to show up in the first or second position whenever anyone compiles a list of top open-source games.

''Wesnoth'''s most notable features include:

* A mature project with continuing active development and frequent improvements
* High quality artwork: both original graphics and music
* Well-balanced by a tireless team of playtesters
* Fun, unique gameplay
* Even after six years of development and with a very solid, fun product already created, there are still plenty of new developers; the number of commits to Subversion is still increasing
* Strong support of internationalization with many supported languages, thus experience in working with non-native English speakers. In fact, more than half of our developers are not native English speakers.

[1] http://www.wesnoth.org/wiki/WesnothPhilosophy

[2] http://www.happypenguin.org/list?sort=avg_rating

[3] http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/

[4] http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/

==== Home page: ====
http://www.wesnoth.org/

==== Main Organization License: ====
GNU General Public License version 2.0 (GPLv2) [Dropdown box answer!]

==== Why is your organization applying to participate in GSoC 2011? What do you hope to gain by participating? ====
Most of our developers have particular areas of interest in which they work. Though they are efficient in their areas, there are other, presently uncovered, areas of the code with a need for improvements but a high barrier to entry for casual contributors.

Our previous SoC experience shows that a motivated, full-time, student can be brought up to date in any area fairly quickly.

By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart some areas of the project that are currently lagging behind.

Moreover, our previous experiences has shown us that SoC developers tend to stay after the end of the Summer of Code and become valuable members of our community. This has been a win in all directions and we want it to happen again.

==== If accepted, would this be your first year participating in GSoC? ====
No

==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. ====
2008 results:
Wesnoth participated in GSoC 2008 with four students. Out of these, two were great successes (that is they became full-fledge developers before the actual start of GSoC), did huge improvement during GSoC (A new recruitment algorithm for the AI and the basic structure for a new map editor, the student finished this work after the summer), and are still active developers in the Wesnoth community.

Of the two other, one of them was very active for the first half of GSoC and provided some useful infrastructure for AI development that we used as base in GSoC 2009, but was much less active and didn't reach expectations for the second half of GSoC. The lesson we learned is that great students should be left on their own, that's the best way to have them work, but average students should be monitored much more closely than we did. If things seems to start to go wrong, it's important to react very quick, to meet with other mentors and get things back on track early.

Timezone problems were also a serious barrier for student/mentor communication, and we will take that more into account when pairing mentors and students

For our other students, multiple problems collectively led to failure
* We should enforce IRC communication, E-mail is a barrier. This applies both for students and mentors. Both should be on IRC several hours a day, with overlapping hours.
* We should be more strict about mid-term evaluation. If the student is slightly lacking at mid-term we should give a clear message that he needs to get back on track.

2009 results:
In 2009 we mentored 6 students as part of Summer of Code. Out of these 5 projects were a success. From those 5 developers 3 are still part of our core development group and still maintain and improve the work they submitted as part of Summer of Code. One of the students even became the "head" of our AI development department and wants to mentor a student this year. For a summary of the 2009 results have a look at [1].

Sadly one student was not able to continue his work past midterm due to his computer failing completely as well as personal problems that we won't delve into further here. It was not a salvageable situation.

[1] http://forums.wesnoth.org/viewtopic.php?f=5&t=26955

==== If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006. ====
2008: 2/4
2009: 5/6
2010: 4/4

==== What is the URL for your ideas page? ====
http://wiki.wesnoth.org/SummerOfCodeIdeas

==== What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2011. If your organization uses more than one list, please make sure to include a description of the list so students know which to use. ====
The main development mailing list is "wesnoth-dev@gna.org". Our main means of communications is our IRC channel on freenode. If you have questions you should ask them in #wesnoth-dev on irc.freenode.net and wait for a reply (might take some hours!). The Wesnoth related channels are logged in public and the logs tend to be read by developers.

==== What is the main IRC channel for your organization? ====
#wesnoth-dev on irc.freenode.net

==== Does your organization have an application template you would like to see students use? If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2011 site. ====
We plan mainly to meet potential students through our IRC channel, but the following questions are Wesnoth specific and are worth pondering for any student, even if we don't need a formal answer. So please beside just answering these questions consider visiting us in IRC: #wesnoth-dev on irc.freenode.net. This is where most of our work takes place and participating in IRC is mandatory for GSoC students participating with Wesnoth. Our experience is that this is the easiest way to communicate and solve problems that come up.

1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

1.4) Why do you want to participate in summer of code?

1.5) What are you studying, subject, level and school?

1.6) What country are you from, at what time are you most likely to be able to join IRC?

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

2) Experience

2.1) What programs/software have you worked on before?

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or gameplay?

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

3.2) What spoken languages are you fluent in?

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

3.6) Are you good at sorting useful criticisms from useless ones?

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

4.2) If you have invented your own project, please describe the project and the scope.

4.3) Why did you choose this project?

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

4.5) Include as much technical detail about your implementation as you can

4.6) What do you expect to gain from this project?

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
* Subversion (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* Python (optional, mainly used for tools)
* build environments (eg cmake/autotools/scons)
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)

5.2) Which tools do you normally use for development? Why do you use them?

5.3) What programming languages are you fluent in?

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

In general please try to be as verbose as possible in your answers and feel free to elaborate.

==== What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible. ====
Our first criterion was that all the people had to be volunteers. According to other open source projects and our experience from the last two years, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.

Boucman is one of the oldest active developers around. He has rewritten the whole animation engine and made it an easily pluggable system allowing artists to easily specify exactly how they want the units to appear. He also started many community oriented projects like the Art Contribution[1] section of the wiki (now deprecated) and the WML Reference Manual[2]. He is responsible for dispatching and sorting the patches at http://patches.wesnoth.org that has created the new developer process we currently use. Boucman was a mentor in 2008, 2009 and 2010.

Yurii Chernyi (Crab) has joined the team in 2009, taking part in Google Summer of Code 2009, and staying with the project as a developer after successful completion of GSoC. He's an expert on all aspects of current Wesnoth AI codebase (having fully reorganized it as part of GSoC 2009), and has fixed numerous bugs all over Wesnoth. He is experienced in teaching other people, in areas like programming languages and math.

Mordante is one of the most active developers on our IRC channel. Not only has he done preliminary studies and coding in multiple areas that are candidates for Summer of Code ideas, he also is one of the coders with the best overview of the Wesnoth code. A large part of his work involves refactoring and polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base. He is currently completing a rewrite of the Wesnoth GUI library, making all windows configurable through WML. This should make it easier to use Wesnoth on different resolutions, from small handheld devices to large 30 inch screens. Mordante was a mentor in 2008, 2009 and 2010.

All other developers listed in the ideas page are the leading capacities we do have for the respecting areas. Have a look at our list of "people who to contact" [3] for an easy reference. In general all our developers will mentor all students. That is, questions should just be asked in our IRC channel, where basically every developer who has an idea can and will directly answer.

When choosing the mentors, we have kept in mind that most developers can answer most technical questions, and we have chosen people that are well known for interacting with new-comers/external developers and can provide general guidance and design advice, more than people with specific technical knowledge.

[1] http://wiki.wesnoth.org/UnsortedContrib

[2] http://wiki.wesnoth.org/ReferenceWML

[3] http://wiki.wesnoth.org/SoC_People_to_bug_on_IRC

==== What is your plan for dealing with disappearing students? ====
The first thing to do is to avoid this situation altogether.

Wesnoth is a game, and as such has lots of developers that are not coders. In particular, artists are well known in the Wesnoth community for being very sensitive about criticism and our community is used to people being sensitive to critics.

We will try to choose students that accept criticism and are able to filter constructive criticism from useless one. The Wesnoth developer community is used to judging people according to these criteria and the special title we are going to give to applicants will allow us to easily spot any such problems and discuss them before they grow out of control.

If a student disappears, their mentor will be in charge of recontacting the student to see what is going wrong (available time, tension with other developers, with members of the community etc...). Depending on the actual problem, the mentor and the student will have to agree on possible ways to defuse the problem.

If a student disappears completely and there is no way to get back to them, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have SVN write access, so most of the work will be committed either to trunk or to a specific branch) and find a core developer to take on the job. This will probably be slower and less effective for the project, but it's the best we can do.

==== What is your plan for dealing with disappearing mentors? ====
All our mentors are long time developers that volunteered for the job, so we don't expect that to happen. We observed in during the last years the amount of time required to mentor, and our mentors accepted the job knowing the amount of work it involved. All of this years mentors mentored last year as well.

However, should it happen, we would continue to mentor as a developer community the student until we find a new "official" mentor to take on the job.

==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====
Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two (non trival) patches... you're in". With other words, anybody that is able to get two non-trivial patches applied is offered commit privileges.
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our EasyCoding pages [1] (these projects are usually a couple of hours long and hve been chosen to provide easy access to the respective area of code).

Usually, patches go back and forth a couple of times, to make sure that all secondary things are in place (indenting, coding style, modified buildfiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to keep our project alive.

If the student is proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

In 2008, 2009 and 2010 all students that were accepted (and a couple more) managed to have commit access before the start of the coding phase. We consider that this policy was successful and we plan to keep it this year.

We also plan to give a special forum title to any students. This will allow all forum members to tell them apart from normal users and give them read/write access to the developer only forums. This will also allow us to quickly spot any problem they might have interacting with the player community. We have a very mature developer community, but our player community is made of all sort of people of all age and education, and it can sometimes be rough.

[1] http://wiki.wesnoth.org/EasyCoding

==== If you are a small or new organization applying to GSoC, please list a larger, established GSoC organization or a Googler that can vouch for you here. ====

==== If you are a large organization who is vouching for a small organization applying to GSoC for their first time this year, please list their name and why you think they'd be good candidates for GSoC here: ====
* Darktable:
Darktable (see http://darktable.sourceforge.net/ and https://sourceforge.net/apps/trac/darktable/wiki/GSOC) is an open source raw development tool.

There are currently no major open source raw development tools. Multiple tools cover the need (ufraw, rawtherapee etc...) but most of them are targeting technical users with interest in photography or signal processing experts rather than "normal" photographer.

Darktable has a very good UI designed around what most photographers expects. It is also a project which is at this interesting stage where there is a solid infrastructure and it needs developer to do the fun part of adding new feature. This is the stage of a project which is the most interesting for developers to join.

The Darktable development community is rather small (3 active developers plus occasional contributors). It could use the extra manpower but is large enough to mentor a student into a core developer pretty fast.

Chances of a student finding it interesting are high, chances of the student bringing major contributions to the project are very high

* Unknown Horizons:
Unknown Horizons (http://www.unknown-horizons.org/) is a 2D realtime strategy simulation with an emphasis on economy and city building.

This is a smaller open source game project with a really dedicated core team of developers. During our talks with the dev who wants to work as admin it was easy to see that they do think about what they do and got some well working infrastructure. Even though the team is rather small at the moment, they are well suited to handle some students and the project has a proven record of being able to actually release something and continue working on the code. Beside their abilities it is always good to support open source gaming, especially when it comes to rather underrepresented areas like real time strategy games.

==== Anything else you'd like to tell us? ====
There is nothing more to say.

==== Backup Admin (Link ID): ====
noy

==== Admin Agreement: ====
(some terms of service by Google that have to be agreed upon)

SoC Information for Google

2011-03-08T21:22:21Z

SkeletonCrew: /* What steps will you take to encourage students to interact with your project's community before, during and after the program? */ more year updates

{{Template:SoC2010}}

== SoC Information for Google ==
This is the info that we submit to google as Application in Summer of Code (current status: 2010). The submitter automatically becomes primary Admin. Most entries are mandatory and have to be filled out before the application can be submitted.

==== Organization Name: ====
Battle for Wesnoth

==== Description: ====
''Battle for Wesnoth'', or simply ''Wesnoth'', is a free, turn-based strategy game with role-playing elements that was designed in June 2003 by David White (Sirp).

Although the core rules are fairly simple and meant to be easily learned[1], they provide interesting gameplay and rich tactical options. A major strength of the project is the Wesnoth Markup Language (WML) for writing scenarios. Programming skills are not required to compose with it, and a large WML-modding community has generated a great deal of user-maintained content. We polish the best of this content and lift it into our official release tree.

The first stable release (1.0) was on October 2, 2005, and the latest stable release (1.8) is anticipated in the next few weeks. Version 1.8 is intended to be a major stable checkpoint. We expect the following development cycle (1.9, leading to 1.10) to premier significant changes in gameplay, UI, and development tools, with many new concepts being introduced. That makes this year probably one of the best years for a SoC student to join, since the open-ended 1.9 will mean much more space to develop novel ideas

''Wesnoth'' is one of the most successful open-source game projects in existence, with an exceptionally large developer base and user community:

* According to Ohloh, a site that collects activity statistics on open-source projects, the ''Wesnoth'' development effort is in the top 2% of largest and most active projects.
* We support two multiplayer game servers (stable and development) with a usual minimum load of more than a hundred players
* More than two thousands downloads a day
* 4.5 million downloads via SourceForge; many more via various mirrors of Linux distributions
* Best rated game at the Linux Game Tome[2]
* Game of the year 2007, 2008, and 2009, 2010 at LinuxQuestions.org[3][4]
* In general, ''Wesnoth'' tends to show up in the first or second position whenever anyone compiles a list of top open-source games.

''Wesnoth'''s most notable features include:

* A mature project with continuing active development and frequent improvements
* High quality artwork: both original graphics and music
* Well-balanced by a tireless team of playtesters
* Fun, unique gameplay
* Even after six years of development and with a very solid, fun product already created, there are still plenty of new developers; the number of commits to Subversion is still increasing
* Strong support of internationalization with many supported languages, thus experience in working with non-native English speakers. In fact, more than half of our developers are not native English speakers.

[1] http://www.wesnoth.org/wiki/WesnothPhilosophy

[2] http://www.happypenguin.org/list?sort=avg_rating

[3] http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/

[4] http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/

==== Home page: ====
http://www.wesnoth.org/

==== Main Organization License: ====
GNU General Public License version 2.0 (GPLv2) [Dropdown box answer!]

==== Why is your organization applying to participate in GSoC 2011? What do you hope to gain by participating? ====
Most of our developers have particular areas of interest in which they work. Though they are efficient in their areas, there are other, presently uncovered, areas of the code with a need for improvements but a high barrier to entry for casual contributors.

Our previous SoC experience shows that a motivated, full-time, student can be brought up to date in any area fairly quickly.

By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart some areas of the project that are currently lagging behind.

Moreover, our previous experiences has shown us that SoC developers tend to stay after the end of the Summer of Code and become valuable members of our community. This has been a win in all directions and we want it to happen again.

==== If accepted, would this be your first year participating in GSoC? ====
No

==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. ====
2008 results:
Wesnoth participated in GSoC 2008 with four students. Out of these, two were great successes (that is they became full-fledge developers before the actual start of GSoC), did huge improvement during GSoC (A new recruitment algorithm for the AI and the basic structure for a new map editor, the student finished this work after the summer), and are still active developers in the Wesnoth community.

Of the two other, one of them was very active for the first half of GSoC and provided some useful infrastructure for AI development that we used as base in GSoC 2009, but was much less active and didn't reach expectations for the second half of GSoC. The lesson we learned is that great students should be left on their own, that's the best way to have them work, but average students should be monitored much more closely than we did. If things seems to start to go wrong, it's important to react very quick, to meet with other mentors and get things back on track early.

Timezone problems were also a serious barrier for student/mentor communication, and we will take that more into account when pairing mentors and students

For our other students, multiple problems collectively led to failure
* We should enforce IRC communication, E-mail is a barrier. This applies both for students and mentors. Both should be on IRC several hours a day, with overlapping hours.
* We should be more strict about mid-term evaluation. If the student is slightly lacking at mid-term we should give a clear message that he needs to get back on track.

2009 results:
In 2009 we mentored 6 students as part of Summer of Code. Out of these 5 projects were a success. From those 5 developers 3 are still part of our core development group and still maintain and improve the work they submitted as part of Summer of Code. One of the students even became the "head" of our AI development department and wants to mentor a student this year. For a summary of the 2009 results have a look at [1].

Sadly one student was not able to continue his work past midterm due to his computer failing completely as well as personal problems that we won't delve into further here. It was not a salvageable situation.

[1] http://forums.wesnoth.org/viewtopic.php?f=5&t=26955

==== If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006. ====
2008: 2/4
2009: 5/6
2010: 4/4

==== What is the URL for your ideas page? ====
http://wiki.wesnoth.org/SummerOfCodeIdeas

==== What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2011. If your organization uses more than one list, please make sure to include a description of the list so students know which to use. ====
The main development mailing list is "wesnoth-dev@gna.org". Our main means of communications is our IRC channel on freenode. If you have questions you should ask them in #wesnoth-dev on irc.freenode.net and wait for a reply (might take some hours!). The Wesnoth related channels are logged in public and the logs tend to be read by developers.

==== What is the main IRC channel for your organization? ====
#wesnoth-dev on irc.freenode.net

==== Does your organization have an application template you would like to see students use? If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2011 site. ====
We plan mainly to meet potential students through our IRC channel, but the following questions are Wesnoth specific and are worth pondering for any student, even if we don't need a formal answer. So please beside just answering these questions consider visiting us in IRC: #wesnoth-dev on irc.freenode.net. This is where most of our work takes place and participating in IRC is mandatory for GSoC students participating with Wesnoth. Our experience is that this is the easiest way to communicate and solve problems that come up.

1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

1.4) Why do you want to participate in summer of code?

1.5) What are you studying, subject, level and school?

1.6) What country are you from, at what time are you most likely to be able to join IRC?

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

2) Experience

2.1) What programs/software have you worked on before?

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or gameplay?

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

3.2) What spoken languages are you fluent in?

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

3.6) Are you good at sorting useful criticisms from useless ones?

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

4.2) If you have invented your own project, please describe the project and the scope.

4.3) Why did you choose this project?

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

4.5) Include as much technical detail about your implementation as you can

4.6) What do you expect to gain from this project?

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
* Subversion (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* Python (optional, mainly used for tools)
* build environments (eg cmake/autotools/scons)
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)

5.2) Which tools do you normally use for development? Why do you use them?

5.3) What programming languages are you fluent in?

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

In general please try to be as verbose as possible in your answers and feel free to elaborate.

==== What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible. ====
Our first criterion was that all the people had to be volunteers. According to other open source projects and our experience from the last two years, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.

Boucman is one of the oldest active developers around. He has rewritten the whole animation engine and made it an easily pluggable system allowing artists to easily specify exactly how they want the units to appear. He also started many community oriented projects like the Art Contribution[1] section of the wiki (now deprecated) and the WML Reference Manual[2]. He is responsible for dispatching and sorting the patches at http://patches.wesnoth.org that has created the new developer process we currently use. Boucman was a mentor in 2008, 2009 and 2010.

Yurii Chernyi (Crab) has joined the team in 2009, taking part in Google Summer of Code 2009, and staying with the project as a developer after successful completion of GSoC. He's an expert on all aspects of current Wesnoth AI codebase (having fully reorganized it as part of GSoC 2009), and has fixed numerous bugs all over Wesnoth. He is experienced in teaching other people, in areas like programming languages and math.

Mordante is one of the most active developers on our IRC channel. Not only has he done preliminary studies and coding in multiple areas that are candidates for Summer of Code ideas, he also is one of the coders with the best overview of the Wesnoth code. A large part of his work involves refactoring and polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base. He is currently completing a rewrite of the Wesnoth GUI library, making all windows configurable through WML. This should make it easier to use Wesnoth on different resolutions, from small handheld devices to large 30 inch screens. Mordante was a mentor in 2008, 2009 and 2010.

All other developers listed in the ideas page are the leading capacities we do have for the respecting areas. Have a look at our list of "people who to contact" [3] for an easy reference. In general all our developers will mentor all students. That is, questions should just be asked in our IRC channel, where basically every developer who has an idea can and will directly answer.

When choosing the mentors, we have kept in mind that most developers can answer most technical questions, and we have chosen people that are well known for interacting with new-comers/external developers and can provide general guidance and design advice, more than people with specific technical knowledge.

[1] http://wiki.wesnoth.org/UnsortedContrib

[2] http://wiki.wesnoth.org/ReferenceWML

[3] http://wiki.wesnoth.org/SoC_People_to_bug_on_IRC

==== What is your plan for dealing with disappearing students? ====
The first thing to do is to avoid this situation altogether.

Wesnoth is a game, and as such has lots of developers that are not coders. In particular, artists are well known in the Wesnoth community for being very sensitive about criticism and our community is used to people being sensitive to critics.

We will try to choose students that accept criticism and are able to filter constructive criticism from useless one. The Wesnoth developer community is used to judging people according to these criteria and the special title we are going to give to applicants will allow us to easily spot any such problems and discuss them before they grow out of control.

If a student disappears, their mentor will be in charge of recontacting the student to see what is going wrong (available time, tension with other developers, with members of the community etc...). Depending on the actual problem, the mentor and the student will have to agree on possible ways to defuse the problem.

If a student disappears completely and there is no way to get back to them, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have SVN write access, so most of the work will be committed either to trunk or to a specific branch) and find a core developer to take on the job. This will probably be slower and less effective for the project, but it's the best we can do.

==== What is your plan for dealing with disappearing mentors? ====
All our mentors are long time developers that volunteered for the job, so we don't expect that to happen. We observed in during the last years the amount of time required to mentor, and our mentors accepted the job knowing the amount of work it involved. All of this years mentors mentored last year as well.

However, should it happen, we would continue to mentor as a developer community the student until we find a new "official" mentor to take on the job.

==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====
Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two (non trival) patches... you're in". With other words, anybody that is able to get two non-trivial patches applied is offered commit privileges.
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our EasyCoding pages [1] (these projects are usually a couple of hours long and hve been chosen to provide easy access to the respective area of code).

Usually, patches go back and forth a couple of times, to make sure that all secondary things are in place (indenting, coding style, modified buildfiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to keep our project alive.

If the student is proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

In 2008, 2009 and 2010 all students that were accepted (and a couple more) managed to have commit access before the start of the coding phase. We consider that this policy was successful and we plan to keep it this year.

We also plan to give a special forum title to any students. This will allow all forum members to tell them apart from normal users and give them read/write access to the developer only forums. This will also allow us to quickly spot any problem they might have interacting with the player community. We have a very mature developer community, but our player community is made of all sort of people of all age and education, and it can sometimes be rough.

[1] http://wiki.wesnoth.org/EasyCoding

==== If you are a small or new organization applying to GSoC, please list a larger, established GSoC organization or a Googler that can vouch for you here. ====

==== If you are a large organization who is vouching for a small organization applying to GSoC for their first time this year, please list their name and why you think they'd be good candidates for GSoC here: ====
* Darktable:
Darktable (see http://darktable.sourceforge.net/ and https://sourceforge.net/apps/trac/darktable/wiki/GSOC) is an open source raw development tool.

There are currently no major open source raw development tools. Multiple tools cover the need (ufraw, rawtherapee etc...) but most of them are targeting technical users with interest in photography or signal processing experts rather than "normal" photographer.

Darktable has a very good UI designed around what most photographers expects. It is also a project which is at this interesting stage where there is a solid infrastructure and it needs developer to do the fun part of adding new feature. This is the stage of a project which is the most interesting for developers to join.

The Darktable development community is rather small (3 active developers plus occasional contributors). It could use the extra manpower but is large enough to mentor a student into a core developer pretty fast.

Chances of a student finding it interesting are high, chances of the student bringing major contributions to the project are very high

* Unknown Horizons:
Unknown Horizons (http://www.unknown-horizons.org/) is a 2D realtime strategy simulation with an emphasis on economy and city building.

This is a smaller open source game project with a really dedicated core team of developers. During our talks with the dev who wants to work as admin it was easy to see that they do think about what they do and got some well working infrastructure. Even though the team is rather small at the moment, they are well suited to handle some students and the project has a proven record of being able to actually release something and continue working on the code. Beside their abilities it is always good to support open source gaming, especially when it comes to rather underrepresented areas like real time strategy games.

==== Anything else you'd like to tell us? ====
There is nothing more to say.

==== Backup Admin (Link ID): ====
noy

==== Admin Agreement: ====
(some terms of service by Google that have to be agreed upon)

SoC Information for Google

2011-03-08T21:21:10Z

SkeletonCrew: /* What is your plan for dealing with disappearing mentors? */ minor update mentioneing last year

{{Template:SoC2010}}

== SoC Information for Google ==
This is the info that we submit to google as Application in Summer of Code (current status: 2010). The submitter automatically becomes primary Admin. Most entries are mandatory and have to be filled out before the application can be submitted.

==== Organization Name: ====
Battle for Wesnoth

==== Description: ====
''Battle for Wesnoth'', or simply ''Wesnoth'', is a free, turn-based strategy game with role-playing elements that was designed in June 2003 by David White (Sirp).

Although the core rules are fairly simple and meant to be easily learned[1], they provide interesting gameplay and rich tactical options. A major strength of the project is the Wesnoth Markup Language (WML) for writing scenarios. Programming skills are not required to compose with it, and a large WML-modding community has generated a great deal of user-maintained content. We polish the best of this content and lift it into our official release tree.

The first stable release (1.0) was on October 2, 2005, and the latest stable release (1.8) is anticipated in the next few weeks. Version 1.8 is intended to be a major stable checkpoint. We expect the following development cycle (1.9, leading to 1.10) to premier significant changes in gameplay, UI, and development tools, with many new concepts being introduced. That makes this year probably one of the best years for a SoC student to join, since the open-ended 1.9 will mean much more space to develop novel ideas

''Wesnoth'' is one of the most successful open-source game projects in existence, with an exceptionally large developer base and user community:

* According to Ohloh, a site that collects activity statistics on open-source projects, the ''Wesnoth'' development effort is in the top 2% of largest and most active projects.
* We support two multiplayer game servers (stable and development) with a usual minimum load of more than a hundred players
* More than two thousands downloads a day
* 4.5 million downloads via SourceForge; many more via various mirrors of Linux distributions
* Best rated game at the Linux Game Tome[2]
* Game of the year 2007, 2008, and 2009, 2010 at LinuxQuestions.org[3][4]
* In general, ''Wesnoth'' tends to show up in the first or second position whenever anyone compiles a list of top open-source games.

''Wesnoth'''s most notable features include:

* A mature project with continuing active development and frequent improvements
* High quality artwork: both original graphics and music
* Well-balanced by a tireless team of playtesters
* Fun, unique gameplay
* Even after six years of development and with a very solid, fun product already created, there are still plenty of new developers; the number of commits to Subversion is still increasing
* Strong support of internationalization with many supported languages, thus experience in working with non-native English speakers. In fact, more than half of our developers are not native English speakers.

[1] http://www.wesnoth.org/wiki/WesnothPhilosophy

[2] http://www.happypenguin.org/list?sort=avg_rating

[3] http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/

[4] http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/

==== Home page: ====
http://www.wesnoth.org/

==== Main Organization License: ====
GNU General Public License version 2.0 (GPLv2) [Dropdown box answer!]

==== Why is your organization applying to participate in GSoC 2011? What do you hope to gain by participating? ====
Most of our developers have particular areas of interest in which they work. Though they are efficient in their areas, there are other, presently uncovered, areas of the code with a need for improvements but a high barrier to entry for casual contributors.

Our previous SoC experience shows that a motivated, full-time, student can be brought up to date in any area fairly quickly.

By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart some areas of the project that are currently lagging behind.

Moreover, our previous experiences has shown us that SoC developers tend to stay after the end of the Summer of Code and become valuable members of our community. This has been a win in all directions and we want it to happen again.

==== If accepted, would this be your first year participating in GSoC? ====
No

==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. ====
2008 results:
Wesnoth participated in GSoC 2008 with four students. Out of these, two were great successes (that is they became full-fledge developers before the actual start of GSoC), did huge improvement during GSoC (A new recruitment algorithm for the AI and the basic structure for a new map editor, the student finished this work after the summer), and are still active developers in the Wesnoth community.

Of the two other, one of them was very active for the first half of GSoC and provided some useful infrastructure for AI development that we used as base in GSoC 2009, but was much less active and didn't reach expectations for the second half of GSoC. The lesson we learned is that great students should be left on their own, that's the best way to have them work, but average students should be monitored much more closely than we did. If things seems to start to go wrong, it's important to react very quick, to meet with other mentors and get things back on track early.

Timezone problems were also a serious barrier for student/mentor communication, and we will take that more into account when pairing mentors and students

For our other students, multiple problems collectively led to failure
* We should enforce IRC communication, E-mail is a barrier. This applies both for students and mentors. Both should be on IRC several hours a day, with overlapping hours.
* We should be more strict about mid-term evaluation. If the student is slightly lacking at mid-term we should give a clear message that he needs to get back on track.

2009 results:
In 2009 we mentored 6 students as part of Summer of Code. Out of these 5 projects were a success. From those 5 developers 3 are still part of our core development group and still maintain and improve the work they submitted as part of Summer of Code. One of the students even became the "head" of our AI development department and wants to mentor a student this year. For a summary of the 2009 results have a look at [1].

Sadly one student was not able to continue his work past midterm due to his computer failing completely as well as personal problems that we won't delve into further here. It was not a salvageable situation.

[1] http://forums.wesnoth.org/viewtopic.php?f=5&t=26955

==== If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006. ====
2008: 2/4
2009: 5/6
2010: 4/4

==== What is the URL for your ideas page? ====
http://wiki.wesnoth.org/SummerOfCodeIdeas

==== What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2011. If your organization uses more than one list, please make sure to include a description of the list so students know which to use. ====
The main development mailing list is "wesnoth-dev@gna.org". Our main means of communications is our IRC channel on freenode. If you have questions you should ask them in #wesnoth-dev on irc.freenode.net and wait for a reply (might take some hours!). The Wesnoth related channels are logged in public and the logs tend to be read by developers.

==== What is the main IRC channel for your organization? ====
#wesnoth-dev on irc.freenode.net

==== Does your organization have an application template you would like to see students use? If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2011 site. ====
We plan mainly to meet potential students through our IRC channel, but the following questions are Wesnoth specific and are worth pondering for any student, even if we don't need a formal answer. So please beside just answering these questions consider visiting us in IRC: #wesnoth-dev on irc.freenode.net. This is where most of our work takes place and participating in IRC is mandatory for GSoC students participating with Wesnoth. Our experience is that this is the easiest way to communicate and solve problems that come up.

1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

1.4) Why do you want to participate in summer of code?

1.5) What are you studying, subject, level and school?

1.6) What country are you from, at what time are you most likely to be able to join IRC?

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

2) Experience

2.1) What programs/software have you worked on before?

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or gameplay?

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

3.2) What spoken languages are you fluent in?

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

3.6) Are you good at sorting useful criticisms from useless ones?

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

4.2) If you have invented your own project, please describe the project and the scope.

4.3) Why did you choose this project?

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

4.5) Include as much technical detail about your implementation as you can

4.6) What do you expect to gain from this project?

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
* Subversion (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* Python (optional, mainly used for tools)
* build environments (eg cmake/autotools/scons)
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)

5.2) Which tools do you normally use for development? Why do you use them?

5.3) What programming languages are you fluent in?

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

In general please try to be as verbose as possible in your answers and feel free to elaborate.

==== What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible. ====
Our first criterion was that all the people had to be volunteers. According to other open source projects and our experience from the last two years, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.

Boucman is one of the oldest active developers around. He has rewritten the whole animation engine and made it an easily pluggable system allowing artists to easily specify exactly how they want the units to appear. He also started many community oriented projects like the Art Contribution[1] section of the wiki (now deprecated) and the WML Reference Manual[2]. He is responsible for dispatching and sorting the patches at http://patches.wesnoth.org that has created the new developer process we currently use. Boucman was a mentor in 2008, 2009 and 2010.

Yurii Chernyi (Crab) has joined the team in 2009, taking part in Google Summer of Code 2009, and staying with the project as a developer after successful completion of GSoC. He's an expert on all aspects of current Wesnoth AI codebase (having fully reorganized it as part of GSoC 2009), and has fixed numerous bugs all over Wesnoth. He is experienced in teaching other people, in areas like programming languages and math.

Mordante is one of the most active developers on our IRC channel. Not only has he done preliminary studies and coding in multiple areas that are candidates for Summer of Code ideas, he also is one of the coders with the best overview of the Wesnoth code. A large part of his work involves refactoring and polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base. He is currently completing a rewrite of the Wesnoth GUI library, making all windows configurable through WML. This should make it easier to use Wesnoth on different resolutions, from small handheld devices to large 30 inch screens. Mordante was a mentor in 2008, 2009 and 2010.

All other developers listed in the ideas page are the leading capacities we do have for the respecting areas. Have a look at our list of "people who to contact" [3] for an easy reference. In general all our developers will mentor all students. That is, questions should just be asked in our IRC channel, where basically every developer who has an idea can and will directly answer.

When choosing the mentors, we have kept in mind that most developers can answer most technical questions, and we have chosen people that are well known for interacting with new-comers/external developers and can provide general guidance and design advice, more than people with specific technical knowledge.

[1] http://wiki.wesnoth.org/UnsortedContrib

[2] http://wiki.wesnoth.org/ReferenceWML

[3] http://wiki.wesnoth.org/SoC_People_to_bug_on_IRC

==== What is your plan for dealing with disappearing students? ====
The first thing to do is to avoid this situation altogether.

Wesnoth is a game, and as such has lots of developers that are not coders. In particular, artists are well known in the Wesnoth community for being very sensitive about criticism and our community is used to people being sensitive to critics.

We will try to choose students that accept criticism and are able to filter constructive criticism from useless one. The Wesnoth developer community is used to judging people according to these criteria and the special title we are going to give to applicants will allow us to easily spot any such problems and discuss them before they grow out of control.

If a student disappears, their mentor will be in charge of recontacting the student to see what is going wrong (available time, tension with other developers, with members of the community etc...). Depending on the actual problem, the mentor and the student will have to agree on possible ways to defuse the problem.

If a student disappears completely and there is no way to get back to them, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have SVN write access, so most of the work will be committed either to trunk or to a specific branch) and find a core developer to take on the job. This will probably be slower and less effective for the project, but it's the best we can do.

==== What is your plan for dealing with disappearing mentors? ====
All our mentors are long time developers that volunteered for the job, so we don't expect that to happen. We observed in during the last years the amount of time required to mentor, and our mentors accepted the job knowing the amount of work it involved. All of this years mentors mentored last year as well.

However, should it happen, we would continue to mentor as a developer community the student until we find a new "official" mentor to take on the job.

==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====
Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two (non trival) patches... you're in". With other words, anybody that is able to get two non-trivial patches applied is offered commit privileges.
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our EasyCoding pages [1] (these projects are usually a couple of hours long and hve been chosen to provide easy access to the respective area of code).

Usually, patches go back and forth a couple of times, to make sure that all secondary things are in place (indenting, coding style, modified buildfiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to keep our project alive.

If the student is proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

In 2008 and 2009 all students that were accepted (and a couple more) managed to have commit access before the start of the coding phase. We consider that this policy was successful and we plan to keep it this year.

We also plan to give a special forum title to any students. This will allow all forum members to tell them apart from normal users and give them read/write access to the developer only forums. This will also allow us to quickly spot any problem they might have interacting with the player community. We have a very mature developer community, but our player community is made of all sort of people of all age and education, and it can sometimes be rough.

[1] http://wiki.wesnoth.org/EasyCoding

==== If you are a small or new organization applying to GSoC, please list a larger, established GSoC organization or a Googler that can vouch for you here. ====

==== If you are a large organization who is vouching for a small organization applying to GSoC for their first time this year, please list their name and why you think they'd be good candidates for GSoC here: ====
* Darktable:
Darktable (see http://darktable.sourceforge.net/ and https://sourceforge.net/apps/trac/darktable/wiki/GSOC) is an open source raw development tool.

There are currently no major open source raw development tools. Multiple tools cover the need (ufraw, rawtherapee etc...) but most of them are targeting technical users with interest in photography or signal processing experts rather than "normal" photographer.

Darktable has a very good UI designed around what most photographers expects. It is also a project which is at this interesting stage where there is a solid infrastructure and it needs developer to do the fun part of adding new feature. This is the stage of a project which is the most interesting for developers to join.

The Darktable development community is rather small (3 active developers plus occasional contributors). It could use the extra manpower but is large enough to mentor a student into a core developer pretty fast.

Chances of a student finding it interesting are high, chances of the student bringing major contributions to the project are very high

* Unknown Horizons:
Unknown Horizons (http://www.unknown-horizons.org/) is a 2D realtime strategy simulation with an emphasis on economy and city building.

This is a smaller open source game project with a really dedicated core team of developers. During our talks with the dev who wants to work as admin it was easy to see that they do think about what they do and got some well working infrastructure. Even though the team is rather small at the moment, they are well suited to handle some students and the project has a proven record of being able to actually release something and continue working on the code. Beside their abilities it is always good to support open source gaming, especially when it comes to rather underrepresented areas like real time strategy games.

==== Anything else you'd like to tell us? ====
There is nothing more to say.

==== Backup Admin (Link ID): ====
noy

==== Admin Agreement: ====
(some terms of service by Google that have to be agreed upon)

SoC Information for Google

2011-03-08T21:16:26Z

SkeletonCrew: /* What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible. */ updated years

{{Template:SoC2010}}

== SoC Information for Google ==
This is the info that we submit to google as Application in Summer of Code (current status: 2010). The submitter automatically becomes primary Admin. Most entries are mandatory and have to be filled out before the application can be submitted.

==== Organization Name: ====
Battle for Wesnoth

==== Description: ====
''Battle for Wesnoth'', or simply ''Wesnoth'', is a free, turn-based strategy game with role-playing elements that was designed in June 2003 by David White (Sirp).

Although the core rules are fairly simple and meant to be easily learned[1], they provide interesting gameplay and rich tactical options. A major strength of the project is the Wesnoth Markup Language (WML) for writing scenarios. Programming skills are not required to compose with it, and a large WML-modding community has generated a great deal of user-maintained content. We polish the best of this content and lift it into our official release tree.

The first stable release (1.0) was on October 2, 2005, and the latest stable release (1.8) is anticipated in the next few weeks. Version 1.8 is intended to be a major stable checkpoint. We expect the following development cycle (1.9, leading to 1.10) to premier significant changes in gameplay, UI, and development tools, with many new concepts being introduced. That makes this year probably one of the best years for a SoC student to join, since the open-ended 1.9 will mean much more space to develop novel ideas

''Wesnoth'' is one of the most successful open-source game projects in existence, with an exceptionally large developer base and user community:

* According to Ohloh, a site that collects activity statistics on open-source projects, the ''Wesnoth'' development effort is in the top 2% of largest and most active projects.
* We support two multiplayer game servers (stable and development) with a usual minimum load of more than a hundred players
* More than two thousands downloads a day
* 4.5 million downloads via SourceForge; many more via various mirrors of Linux distributions
* Best rated game at the Linux Game Tome[2]
* Game of the year 2007, 2008, and 2009, 2010 at LinuxQuestions.org[3][4]
* In general, ''Wesnoth'' tends to show up in the first or second position whenever anyone compiles a list of top open-source games.

''Wesnoth'''s most notable features include:

* A mature project with continuing active development and frequent improvements
* High quality artwork: both original graphics and music
* Well-balanced by a tireless team of playtesters
* Fun, unique gameplay
* Even after six years of development and with a very solid, fun product already created, there are still plenty of new developers; the number of commits to Subversion is still increasing
* Strong support of internationalization with many supported languages, thus experience in working with non-native English speakers. In fact, more than half of our developers are not native English speakers.

[1] http://www.wesnoth.org/wiki/WesnothPhilosophy

[2] http://www.happypenguin.org/list?sort=avg_rating

[3] http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/

[4] http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/

==== Home page: ====
http://www.wesnoth.org/

==== Main Organization License: ====
GNU General Public License version 2.0 (GPLv2) [Dropdown box answer!]

==== Why is your organization applying to participate in GSoC 2011? What do you hope to gain by participating? ====
Most of our developers have particular areas of interest in which they work. Though they are efficient in their areas, there are other, presently uncovered, areas of the code with a need for improvements but a high barrier to entry for casual contributors.

Our previous SoC experience shows that a motivated, full-time, student can be brought up to date in any area fairly quickly.

By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart some areas of the project that are currently lagging behind.

Moreover, our previous experiences has shown us that SoC developers tend to stay after the end of the Summer of Code and become valuable members of our community. This has been a win in all directions and we want it to happen again.

==== If accepted, would this be your first year participating in GSoC? ====
No

==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. ====
2008 results:
Wesnoth participated in GSoC 2008 with four students. Out of these, two were great successes (that is they became full-fledge developers before the actual start of GSoC), did huge improvement during GSoC (A new recruitment algorithm for the AI and the basic structure for a new map editor, the student finished this work after the summer), and are still active developers in the Wesnoth community.

Of the two other, one of them was very active for the first half of GSoC and provided some useful infrastructure for AI development that we used as base in GSoC 2009, but was much less active and didn't reach expectations for the second half of GSoC. The lesson we learned is that great students should be left on their own, that's the best way to have them work, but average students should be monitored much more closely than we did. If things seems to start to go wrong, it's important to react very quick, to meet with other mentors and get things back on track early.

Timezone problems were also a serious barrier for student/mentor communication, and we will take that more into account when pairing mentors and students

For our other students, multiple problems collectively led to failure
* We should enforce IRC communication, E-mail is a barrier. This applies both for students and mentors. Both should be on IRC several hours a day, with overlapping hours.
* We should be more strict about mid-term evaluation. If the student is slightly lacking at mid-term we should give a clear message that he needs to get back on track.

2009 results:
In 2009 we mentored 6 students as part of Summer of Code. Out of these 5 projects were a success. From those 5 developers 3 are still part of our core development group and still maintain and improve the work they submitted as part of Summer of Code. One of the students even became the "head" of our AI development department and wants to mentor a student this year. For a summary of the 2009 results have a look at [1].

Sadly one student was not able to continue his work past midterm due to his computer failing completely as well as personal problems that we won't delve into further here. It was not a salvageable situation.

[1] http://forums.wesnoth.org/viewtopic.php?f=5&t=26955

==== If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006. ====
2008: 2/4
2009: 5/6
2010: 4/4

==== What is the URL for your ideas page? ====
http://wiki.wesnoth.org/SummerOfCodeIdeas

==== What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2011. If your organization uses more than one list, please make sure to include a description of the list so students know which to use. ====
The main development mailing list is "wesnoth-dev@gna.org". Our main means of communications is our IRC channel on freenode. If you have questions you should ask them in #wesnoth-dev on irc.freenode.net and wait for a reply (might take some hours!). The Wesnoth related channels are logged in public and the logs tend to be read by developers.

==== What is the main IRC channel for your organization? ====
#wesnoth-dev on irc.freenode.net

==== Does your organization have an application template you would like to see students use? If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2011 site. ====
We plan mainly to meet potential students through our IRC channel, but the following questions are Wesnoth specific and are worth pondering for any student, even if we don't need a formal answer. So please beside just answering these questions consider visiting us in IRC: #wesnoth-dev on irc.freenode.net. This is where most of our work takes place and participating in IRC is mandatory for GSoC students participating with Wesnoth. Our experience is that this is the easiest way to communicate and solve problems that come up.

1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

1.4) Why do you want to participate in summer of code?

1.5) What are you studying, subject, level and school?

1.6) What country are you from, at what time are you most likely to be able to join IRC?

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

2) Experience

2.1) What programs/software have you worked on before?

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or gameplay?

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

3.2) What spoken languages are you fluent in?

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

3.6) Are you good at sorting useful criticisms from useless ones?

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

4.2) If you have invented your own project, please describe the project and the scope.

4.3) Why did you choose this project?

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

4.5) Include as much technical detail about your implementation as you can

4.6) What do you expect to gain from this project?

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
* Subversion (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* Python (optional, mainly used for tools)
* build environments (eg cmake/autotools/scons)
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)

5.2) Which tools do you normally use for development? Why do you use them?

5.3) What programming languages are you fluent in?

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

In general please try to be as verbose as possible in your answers and feel free to elaborate.

==== What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible. ====
Our first criterion was that all the people had to be volunteers. According to other open source projects and our experience from the last two years, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.

Boucman is one of the oldest active developers around. He has rewritten the whole animation engine and made it an easily pluggable system allowing artists to easily specify exactly how they want the units to appear. He also started many community oriented projects like the Art Contribution[1] section of the wiki (now deprecated) and the WML Reference Manual[2]. He is responsible for dispatching and sorting the patches at http://patches.wesnoth.org that has created the new developer process we currently use. Boucman was a mentor in 2008, 2009 and 2010.

Yurii Chernyi (Crab) has joined the team in 2009, taking part in Google Summer of Code 2009, and staying with the project as a developer after successful completion of GSoC. He's an expert on all aspects of current Wesnoth AI codebase (having fully reorganized it as part of GSoC 2009), and has fixed numerous bugs all over Wesnoth. He is experienced in teaching other people, in areas like programming languages and math.

Mordante is one of the most active developers on our IRC channel. Not only has he done preliminary studies and coding in multiple areas that are candidates for Summer of Code ideas, he also is one of the coders with the best overview of the Wesnoth code. A large part of his work involves refactoring and polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base. He is currently completing a rewrite of the Wesnoth GUI library, making all windows configurable through WML. This should make it easier to use Wesnoth on different resolutions, from small handheld devices to large 30 inch screens. Mordante was a mentor in 2008, 2009 and 2010.

All other developers listed in the ideas page are the leading capacities we do have for the respecting areas. Have a look at our list of "people who to contact" [3] for an easy reference. In general all our developers will mentor all students. That is, questions should just be asked in our IRC channel, where basically every developer who has an idea can and will directly answer.

When choosing the mentors, we have kept in mind that most developers can answer most technical questions, and we have chosen people that are well known for interacting with new-comers/external developers and can provide general guidance and design advice, more than people with specific technical knowledge.

[1] http://wiki.wesnoth.org/UnsortedContrib

[2] http://wiki.wesnoth.org/ReferenceWML

[3] http://wiki.wesnoth.org/SoC_People_to_bug_on_IRC

==== What is your plan for dealing with disappearing students? ====
The first thing to do is to avoid this situation altogether.

Wesnoth is a game, and as such has lots of developers that are not coders. In particular, artists are well known in the Wesnoth community for being very sensitive about criticism and our community is used to people being sensitive to critics.

We will try to choose students that accept criticism and are able to filter constructive criticism from useless one. The Wesnoth developer community is used to judging people according to these criteria and the special title we are going to give to applicants will allow us to easily spot any such problems and discuss them before they grow out of control.

If a student disappears, their mentor will be in charge of recontacting the student to see what is going wrong (available time, tension with other developers, with members of the community etc...). Depending on the actual problem, the mentor and the student will have to agree on possible ways to defuse the problem.

If a student disappears completely and there is no way to get back to them, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have SVN write access, so most of the work will be committed either to trunk or to a specific branch) and find a core developer to take on the job. This will probably be slower and less effective for the project, but it's the best we can do.

==== What is your plan for dealing with disappearing mentors? ====
All our mentors are long time developers that volunteered for the job, so we don't expect that to happen. We observed in 2008 the amount of time required to mentor, and our mentors accepted the job knowing the amount of work it involved. Most of them were mentors last year too.

However, should it happen, we would continue to mentor as a developer community the student until we find a new "official" mentor to take on the job.

==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====
Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two (non trival) patches... you're in". With other words, anybody that is able to get two non-trivial patches applied is offered commit privileges.
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our EasyCoding pages [1] (these projects are usually a couple of hours long and hve been chosen to provide easy access to the respective area of code).

Usually, patches go back and forth a couple of times, to make sure that all secondary things are in place (indenting, coding style, modified buildfiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to keep our project alive.

If the student is proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

In 2008 and 2009 all students that were accepted (and a couple more) managed to have commit access before the start of the coding phase. We consider that this policy was successful and we plan to keep it this year.

We also plan to give a special forum title to any students. This will allow all forum members to tell them apart from normal users and give them read/write access to the developer only forums. This will also allow us to quickly spot any problem they might have interacting with the player community. We have a very mature developer community, but our player community is made of all sort of people of all age and education, and it can sometimes be rough.

[1] http://wiki.wesnoth.org/EasyCoding

==== If you are a small or new organization applying to GSoC, please list a larger, established GSoC organization or a Googler that can vouch for you here. ====

==== If you are a large organization who is vouching for a small organization applying to GSoC for their first time this year, please list their name and why you think they'd be good candidates for GSoC here: ====
* Darktable:
Darktable (see http://darktable.sourceforge.net/ and https://sourceforge.net/apps/trac/darktable/wiki/GSOC) is an open source raw development tool.

There are currently no major open source raw development tools. Multiple tools cover the need (ufraw, rawtherapee etc...) but most of them are targeting technical users with interest in photography or signal processing experts rather than "normal" photographer.

Darktable has a very good UI designed around what most photographers expects. It is also a project which is at this interesting stage where there is a solid infrastructure and it needs developer to do the fun part of adding new feature. This is the stage of a project which is the most interesting for developers to join.

The Darktable development community is rather small (3 active developers plus occasional contributors). It could use the extra manpower but is large enough to mentor a student into a core developer pretty fast.

Chances of a student finding it interesting are high, chances of the student bringing major contributions to the project are very high

* Unknown Horizons:
Unknown Horizons (http://www.unknown-horizons.org/) is a 2D realtime strategy simulation with an emphasis on economy and city building.

This is a smaller open source game project with a really dedicated core team of developers. During our talks with the dev who wants to work as admin it was easy to see that they do think about what they do and got some well working infrastructure. Even though the team is rather small at the moment, they are well suited to handle some students and the project has a proven record of being able to actually release something and continue working on the code. Beside their abilities it is always good to support open source gaming, especially when it comes to rather underrepresented areas like real time strategy games.

==== Anything else you'd like to tell us? ====
There is nothing more to say.

==== Backup Admin (Link ID): ====
noy

==== Admin Agreement: ====
(some terms of service by Google that have to be agreed upon)

SoC Information for Google

2011-03-08T21:04:33Z

SkeletonCrew: /* Description: */ fixed missing newline

{{Template:SoC2010}}

== SoC Information for Google ==
This is the info that we submit to google as Application in Summer of Code (current status: 2010). The submitter automatically becomes primary Admin. Most entries are mandatory and have to be filled out before the application can be submitted.

==== Organization Name: ====
Battle for Wesnoth

==== Description: ====
''Battle for Wesnoth'', or simply ''Wesnoth'', is a free, turn-based strategy game with role-playing elements that was designed in June 2003 by David White (Sirp).

Although the core rules are fairly simple and meant to be easily learned[1], they provide interesting gameplay and rich tactical options. A major strength of the project is the Wesnoth Markup Language (WML) for writing scenarios. Programming skills are not required to compose with it, and a large WML-modding community has generated a great deal of user-maintained content. We polish the best of this content and lift it into our official release tree.

The first stable release (1.0) was on October 2, 2005, and the latest stable release (1.8) is anticipated in the next few weeks. Version 1.8 is intended to be a major stable checkpoint. We expect the following development cycle (1.9, leading to 1.10) to premier significant changes in gameplay, UI, and development tools, with many new concepts being introduced. That makes this year probably one of the best years for a SoC student to join, since the open-ended 1.9 will mean much more space to develop novel ideas

''Wesnoth'' is one of the most successful open-source game projects in existence, with an exceptionally large developer base and user community:

* According to Ohloh, a site that collects activity statistics on open-source projects, the ''Wesnoth'' development effort is in the top 2% of largest and most active projects.
* We support two multiplayer game servers (stable and development) with a usual minimum load of more than a hundred players
* More than two thousands downloads a day
* 4.5 million downloads via SourceForge; many more via various mirrors of Linux distributions
* Best rated game at the Linux Game Tome[2]
* Game of the year 2007, 2008, and 2009, 2010 at LinuxQuestions.org[3][4]
* In general, ''Wesnoth'' tends to show up in the first or second position whenever anyone compiles a list of top open-source games.

''Wesnoth'''s most notable features include:

* A mature project with continuing active development and frequent improvements
* High quality artwork: both original graphics and music
* Well-balanced by a tireless team of playtesters
* Fun, unique gameplay
* Even after six years of development and with a very solid, fun product already created, there are still plenty of new developers; the number of commits to Subversion is still increasing
* Strong support of internationalization with many supported languages, thus experience in working with non-native English speakers. In fact, more than half of our developers are not native English speakers.

[1] http://www.wesnoth.org/wiki/WesnothPhilosophy

[2] http://www.happypenguin.org/list?sort=avg_rating

[3] http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/

[4] http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/

==== Home page: ====
http://www.wesnoth.org/

==== Main Organization License: ====
GNU General Public License version 2.0 (GPLv2) [Dropdown box answer!]

==== Why is your organization applying to participate in GSoC 2011? What do you hope to gain by participating? ====
Most of our developers have particular areas of interest in which they work. Though they are efficient in their areas, there are other, presently uncovered, areas of the code with a need for improvements but a high barrier to entry for casual contributors.

Our previous SoC experience shows that a motivated, full-time, student can be brought up to date in any area fairly quickly.

By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart some areas of the project that are currently lagging behind.

Moreover, our previous experiences has shown us that SoC developers tend to stay after the end of the Summer of Code and become valuable members of our community. This has been a win in all directions and we want it to happen again.

==== If accepted, would this be your first year participating in GSoC? ====
No

==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. ====
2008 results:
Wesnoth participated in GSoC 2008 with four students. Out of these, two were great successes (that is they became full-fledge developers before the actual start of GSoC), did huge improvement during GSoC (A new recruitment algorithm for the AI and the basic structure for a new map editor, the student finished this work after the summer), and are still active developers in the Wesnoth community.

Of the two other, one of them was very active for the first half of GSoC and provided some useful infrastructure for AI development that we used as base in GSoC 2009, but was much less active and didn't reach expectations for the second half of GSoC. The lesson we learned is that great students should be left on their own, that's the best way to have them work, but average students should be monitored much more closely than we did. If things seems to start to go wrong, it's important to react very quick, to meet with other mentors and get things back on track early.

Timezone problems were also a serious barrier for student/mentor communication, and we will take that more into account when pairing mentors and students

For our other students, multiple problems collectively led to failure
* We should enforce IRC communication, E-mail is a barrier. This applies both for students and mentors. Both should be on IRC several hours a day, with overlapping hours.
* We should be more strict about mid-term evaluation. If the student is slightly lacking at mid-term we should give a clear message that he needs to get back on track.

2009 results:
In 2009 we mentored 6 students as part of Summer of Code. Out of these 5 projects were a success. From those 5 developers 3 are still part of our core development group and still maintain and improve the work they submitted as part of Summer of Code. One of the students even became the "head" of our AI development department and wants to mentor a student this year. For a summary of the 2009 results have a look at [1].

Sadly one student was not able to continue his work past midterm due to his computer failing completely as well as personal problems that we won't delve into further here. It was not a salvageable situation.

[1] http://forums.wesnoth.org/viewtopic.php?f=5&t=26955

==== If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006. ====
2008: 2/4
2009: 5/6
2010: 4/4

==== What is the URL for your ideas page? ====
http://wiki.wesnoth.org/SummerOfCodeIdeas

==== What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2011. If your organization uses more than one list, please make sure to include a description of the list so students know which to use. ====
The main development mailing list is "wesnoth-dev@gna.org". Our main means of communications is our IRC channel on freenode. If you have questions you should ask them in #wesnoth-dev on irc.freenode.net and wait for a reply (might take some hours!). The Wesnoth related channels are logged in public and the logs tend to be read by developers.

==== What is the main IRC channel for your organization? ====
#wesnoth-dev on irc.freenode.net

==== Does your organization have an application template you would like to see students use? If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2011 site. ====
We plan mainly to meet potential students through our IRC channel, but the following questions are Wesnoth specific and are worth pondering for any student, even if we don't need a formal answer. So please beside just answering these questions consider visiting us in IRC: #wesnoth-dev on irc.freenode.net. This is where most of our work takes place and participating in IRC is mandatory for GSoC students participating with Wesnoth. Our experience is that this is the easiest way to communicate and solve problems that come up.

1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

1.4) Why do you want to participate in summer of code?

1.5) What are you studying, subject, level and school?

1.6) What country are you from, at what time are you most likely to be able to join IRC?

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

2) Experience

2.1) What programs/software have you worked on before?

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or gameplay?

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

3.2) What spoken languages are you fluent in?

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

3.6) Are you good at sorting useful criticisms from useless ones?

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

4.2) If you have invented your own project, please describe the project and the scope.

4.3) Why did you choose this project?

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

4.5) Include as much technical detail about your implementation as you can

4.6) What do you expect to gain from this project?

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
* Subversion (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* Python (optional, mainly used for tools)
* build environments (eg cmake/autotools/scons)
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)

5.2) Which tools do you normally use for development? Why do you use them?

5.3) What programming languages are you fluent in?

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

In general please try to be as verbose as possible in your answers and feel free to elaborate.

==== What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible. ====
Our first criterion was that all the people had to be volunteers. According to other open source projects and our experience from the last two years, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.

Boucman is one of the oldest active developers around. He has rewritten the whole animation engine and made it an easily pluggable system allowing artists to easily specify exactly how they want the units to appear. He also started many community oriented projects like the Art Contribution[1] section of the wiki (now deprecated) and the WML Reference Manual[2]. He is responsible for dispatching and sorting the patches at http://patches.wesnoth.org that has created the new developer process we currently use. Boucman was a mentor in 2008 and 2009.

Yurii Chernyi (Crab) has joined the team in 2009, taking part in Google Summer of Code 2009, and staying with the project as a developer after successful completion of GSoC. He's an expert on all aspects of current Wesnoth AI codebase (having fully reorganized it as part of GSoC 2009), and has fixed numerous bugs all over Wesnoth. He is experienced in teaching other people, in areas like programming languages and math.

Mordante is one of the most active developers on our IRC channel. Not only has he done preliminary studies and coding in multiple areas that are candidates for Summer of Code ideas, he also is one of the coders with the best overview of the Wesnoth code. A large part of his work involves refactoring and polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base. He is currently completing a rewrite of the Wesnoth GUI library, making all windows configurable through WML. This should make it easier to use Wesnoth on different resolutions, from small handheld devices to large 30 inch screens. Mordante was a mentor in 2008 and 2009.

All other developers listed in the ideas page are the leading capacities we do have for the respecting areas. Have a look at our list of "people who to contact" [3] for an easy reference. In general all our developers will mentor all students. That is, questions should just be asked in our IRC channel, where basically every developer who has an idea can and will directly answer.

When choosing the mentors, we have kept in mind that most developers can answer most technical questions, and we have chosen people that are well known for interacting with new-comers/external developers and can provide general guidance and design advice, more than people with specific technical knowledge.

[1] http://wiki.wesnoth.org/UnsortedContrib

[2] http://wiki.wesnoth.org/ReferenceWML

[3] http://wiki.wesnoth.org/SoC_People_to_bug_on_IRC

==== What is your plan for dealing with disappearing students? ====
The first thing to do is to avoid this situation altogether.

Wesnoth is a game, and as such has lots of developers that are not coders. In particular, artists are well known in the Wesnoth community for being very sensitive about criticism and our community is used to people being sensitive to critics.

We will try to choose students that accept criticism and are able to filter constructive criticism from useless one. The Wesnoth developer community is used to judging people according to these criteria and the special title we are going to give to applicants will allow us to easily spot any such problems and discuss them before they grow out of control.

If a student disappears, their mentor will be in charge of recontacting the student to see what is going wrong (available time, tension with other developers, with members of the community etc...). Depending on the actual problem, the mentor and the student will have to agree on possible ways to defuse the problem.

If a student disappears completely and there is no way to get back to them, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have SVN write access, so most of the work will be committed either to trunk or to a specific branch) and find a core developer to take on the job. This will probably be slower and less effective for the project, but it's the best we can do.

==== What is your plan for dealing with disappearing mentors? ====
All our mentors are long time developers that volunteered for the job, so we don't expect that to happen. We observed in 2008 the amount of time required to mentor, and our mentors accepted the job knowing the amount of work it involved. Most of them were mentors last year too.

However, should it happen, we would continue to mentor as a developer community the student until we find a new "official" mentor to take on the job.

==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====
Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two (non trival) patches... you're in". With other words, anybody that is able to get two non-trivial patches applied is offered commit privileges.
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our EasyCoding pages [1] (these projects are usually a couple of hours long and hve been chosen to provide easy access to the respective area of code).

Usually, patches go back and forth a couple of times, to make sure that all secondary things are in place (indenting, coding style, modified buildfiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to keep our project alive.

If the student is proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

In 2008 and 2009 all students that were accepted (and a couple more) managed to have commit access before the start of the coding phase. We consider that this policy was successful and we plan to keep it this year.

We also plan to give a special forum title to any students. This will allow all forum members to tell them apart from normal users and give them read/write access to the developer only forums. This will also allow us to quickly spot any problem they might have interacting with the player community. We have a very mature developer community, but our player community is made of all sort of people of all age and education, and it can sometimes be rough.

[1] http://wiki.wesnoth.org/EasyCoding

==== If you are a small or new organization applying to GSoC, please list a larger, established GSoC organization or a Googler that can vouch for you here. ====

==== If you are a large organization who is vouching for a small organization applying to GSoC for their first time this year, please list their name and why you think they'd be good candidates for GSoC here: ====
* Darktable:
Darktable (see http://darktable.sourceforge.net/ and https://sourceforge.net/apps/trac/darktable/wiki/GSOC) is an open source raw development tool.

There are currently no major open source raw development tools. Multiple tools cover the need (ufraw, rawtherapee etc...) but most of them are targeting technical users with interest in photography or signal processing experts rather than "normal" photographer.

Darktable has a very good UI designed around what most photographers expects. It is also a project which is at this interesting stage where there is a solid infrastructure and it needs developer to do the fun part of adding new feature. This is the stage of a project which is the most interesting for developers to join.

The Darktable development community is rather small (3 active developers plus occasional contributors). It could use the extra manpower but is large enough to mentor a student into a core developer pretty fast.

Chances of a student finding it interesting are high, chances of the student bringing major contributions to the project are very high

* Unknown Horizons:
Unknown Horizons (http://www.unknown-horizons.org/) is a 2D realtime strategy simulation with an emphasis on economy and city building.

This is a smaller open source game project with a really dedicated core team of developers. During our talks with the dev who wants to work as admin it was easy to see that they do think about what they do and got some well working infrastructure. Even though the team is rather small at the moment, they are well suited to handle some students and the project has a proven record of being able to actually release something and continue working on the code. Beside their abilities it is always good to support open source gaming, especially when it comes to rather underrepresented areas like real time strategy games.

==== Anything else you'd like to tell us? ====
There is nothing more to say.

==== Backup Admin (Link ID): ====
noy

==== Admin Agreement: ====
(some terms of service by Google that have to be agreed upon)

SoC Information for Google

2011-03-08T21:03:34Z

SkeletonCrew: /* Description: */ update some statistics

{{Template:SoC2010}}

== SoC Information for Google ==
This is the info that we submit to google as Application in Summer of Code (current status: 2010). The submitter automatically becomes primary Admin. Most entries are mandatory and have to be filled out before the application can be submitted.

==== Organization Name: ====
Battle for Wesnoth

==== Description: ====
''Battle for Wesnoth'', or simply ''Wesnoth'', is a free, turn-based strategy game with role-playing elements that was designed in June 2003 by David White (Sirp).

Although the core rules are fairly simple and meant to be easily learned[1], they provide interesting gameplay and rich tactical options. A major strength of the project is the Wesnoth Markup Language (WML) for writing scenarios. Programming skills are not required to compose with it, and a large WML-modding community has generated a great deal of user-maintained content. We polish the best of this content and lift it into our official release tree.

The first stable release (1.0) was on October 2, 2005, and the latest stable release (1.8) is anticipated in the next few weeks. Version 1.8 is intended to be a major stable checkpoint. We expect the following development cycle (1.9, leading to 1.10) to premier significant changes in gameplay, UI, and development tools, with many new concepts being introduced. That makes this year probably one of the best years for a SoC student to join, since the open-ended 1.9 will mean much more space to develop novel ideas

''Wesnoth'' is one of the most successful open-source game projects in existence, with an exceptionally large developer base and user community:

* According to Ohloh, a site that collects activity statistics on open-source projects, the ''Wesnoth'' development effort is in the top 2% of largest and most active projects.
* We support two multiplayer game servers (stable and development) with a usual minimum load of more than a hundred players
* More than two thousands downloads a day
* 4.5 million downloads via SourceForge; many more via various mirrors of Linux distributions
* Best rated game at the Linux Game Tome[2]
* Game of the year 2007, 2008, and 2009, 2010 at LinuxQuestions.org[3][4]
* In general, ''Wesnoth'' tends to show up in the first or second position whenever anyone compiles a list of top open-source games.

''Wesnoth'''s most notable features include:

* A mature project with continuing active development and frequent improvements
* High quality artwork: both original graphics and music
* Well-balanced by a tireless team of playtesters
* Fun, unique gameplay
* Even after six years of development and with a very solid, fun product already created, there are still plenty of new developers; the number of commits to Subversion is still increasing
* Strong support of internationalization with many supported languages, thus experience in working with non-native English speakers. In fact, more than half of our developers are not native English speakers.

[1] http://www.wesnoth.org/wiki/WesnothPhilosophy

[2] http://www.happypenguin.org/list?sort=avg_rating

[3] http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/
[4] http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/

==== Home page: ====
http://www.wesnoth.org/

==== Main Organization License: ====
GNU General Public License version 2.0 (GPLv2) [Dropdown box answer!]

==== Why is your organization applying to participate in GSoC 2011? What do you hope to gain by participating? ====
Most of our developers have particular areas of interest in which they work. Though they are efficient in their areas, there are other, presently uncovered, areas of the code with a need for improvements but a high barrier to entry for casual contributors.

Our previous SoC experience shows that a motivated, full-time, student can be brought up to date in any area fairly quickly.

By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart some areas of the project that are currently lagging behind.

Moreover, our previous experiences has shown us that SoC developers tend to stay after the end of the Summer of Code and become valuable members of our community. This has been a win in all directions and we want it to happen again.

==== If accepted, would this be your first year participating in GSoC? ====
No

==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. ====
2008 results:
Wesnoth participated in GSoC 2008 with four students. Out of these, two were great successes (that is they became full-fledge developers before the actual start of GSoC), did huge improvement during GSoC (A new recruitment algorithm for the AI and the basic structure for a new map editor, the student finished this work after the summer), and are still active developers in the Wesnoth community.

Of the two other, one of them was very active for the first half of GSoC and provided some useful infrastructure for AI development that we used as base in GSoC 2009, but was much less active and didn't reach expectations for the second half of GSoC. The lesson we learned is that great students should be left on their own, that's the best way to have them work, but average students should be monitored much more closely than we did. If things seems to start to go wrong, it's important to react very quick, to meet with other mentors and get things back on track early.

Timezone problems were also a serious barrier for student/mentor communication, and we will take that more into account when pairing mentors and students

For our other students, multiple problems collectively led to failure
* We should enforce IRC communication, E-mail is a barrier. This applies both for students and mentors. Both should be on IRC several hours a day, with overlapping hours.
* We should be more strict about mid-term evaluation. If the student is slightly lacking at mid-term we should give a clear message that he needs to get back on track.

2009 results:
In 2009 we mentored 6 students as part of Summer of Code. Out of these 5 projects were a success. From those 5 developers 3 are still part of our core development group and still maintain and improve the work they submitted as part of Summer of Code. One of the students even became the "head" of our AI development department and wants to mentor a student this year. For a summary of the 2009 results have a look at [1].

Sadly one student was not able to continue his work past midterm due to his computer failing completely as well as personal problems that we won't delve into further here. It was not a salvageable situation.

[1] http://forums.wesnoth.org/viewtopic.php?f=5&t=26955

==== If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006. ====
2008: 2/4
2009: 5/6
2010: 4/4

==== What is the URL for your ideas page? ====
http://wiki.wesnoth.org/SummerOfCodeIdeas

==== What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2011. If your organization uses more than one list, please make sure to include a description of the list so students know which to use. ====
The main development mailing list is "wesnoth-dev@gna.org". Our main means of communications is our IRC channel on freenode. If you have questions you should ask them in #wesnoth-dev on irc.freenode.net and wait for a reply (might take some hours!). The Wesnoth related channels are logged in public and the logs tend to be read by developers.

==== What is the main IRC channel for your organization? ====
#wesnoth-dev on irc.freenode.net

==== Does your organization have an application template you would like to see students use? If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2011 site. ====
We plan mainly to meet potential students through our IRC channel, but the following questions are Wesnoth specific and are worth pondering for any student, even if we don't need a formal answer. So please beside just answering these questions consider visiting us in IRC: #wesnoth-dev on irc.freenode.net. This is where most of our work takes place and participating in IRC is mandatory for GSoC students participating with Wesnoth. Our experience is that this is the easiest way to communicate and solve problems that come up.

1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

1.4) Why do you want to participate in summer of code?

1.5) What are you studying, subject, level and school?

1.6) What country are you from, at what time are you most likely to be able to join IRC?

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

2) Experience

2.1) What programs/software have you worked on before?

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or gameplay?

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

3.2) What spoken languages are you fluent in?

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

3.6) Are you good at sorting useful criticisms from useless ones?

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

4.2) If you have invented your own project, please describe the project and the scope.

4.3) Why did you choose this project?

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

4.5) Include as much technical detail about your implementation as you can

4.6) What do you expect to gain from this project?

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
* Subversion (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* Python (optional, mainly used for tools)
* build environments (eg cmake/autotools/scons)
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)

5.2) Which tools do you normally use for development? Why do you use them?

5.3) What programming languages are you fluent in?

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

In general please try to be as verbose as possible in your answers and feel free to elaborate.

==== What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible. ====
Our first criterion was that all the people had to be volunteers. According to other open source projects and our experience from the last two years, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.

Boucman is one of the oldest active developers around. He has rewritten the whole animation engine and made it an easily pluggable system allowing artists to easily specify exactly how they want the units to appear. He also started many community oriented projects like the Art Contribution[1] section of the wiki (now deprecated) and the WML Reference Manual[2]. He is responsible for dispatching and sorting the patches at http://patches.wesnoth.org that has created the new developer process we currently use. Boucman was a mentor in 2008 and 2009.

Yurii Chernyi (Crab) has joined the team in 2009, taking part in Google Summer of Code 2009, and staying with the project as a developer after successful completion of GSoC. He's an expert on all aspects of current Wesnoth AI codebase (having fully reorganized it as part of GSoC 2009), and has fixed numerous bugs all over Wesnoth. He is experienced in teaching other people, in areas like programming languages and math.

Mordante is one of the most active developers on our IRC channel. Not only has he done preliminary studies and coding in multiple areas that are candidates for Summer of Code ideas, he also is one of the coders with the best overview of the Wesnoth code. A large part of his work involves refactoring and polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base. He is currently completing a rewrite of the Wesnoth GUI library, making all windows configurable through WML. This should make it easier to use Wesnoth on different resolutions, from small handheld devices to large 30 inch screens. Mordante was a mentor in 2008 and 2009.

All other developers listed in the ideas page are the leading capacities we do have for the respecting areas. Have a look at our list of "people who to contact" [3] for an easy reference. In general all our developers will mentor all students. That is, questions should just be asked in our IRC channel, where basically every developer who has an idea can and will directly answer.

When choosing the mentors, we have kept in mind that most developers can answer most technical questions, and we have chosen people that are well known for interacting with new-comers/external developers and can provide general guidance and design advice, more than people with specific technical knowledge.

[1] http://wiki.wesnoth.org/UnsortedContrib

[2] http://wiki.wesnoth.org/ReferenceWML

[3] http://wiki.wesnoth.org/SoC_People_to_bug_on_IRC

==== What is your plan for dealing with disappearing students? ====
The first thing to do is to avoid this situation altogether.

Wesnoth is a game, and as such has lots of developers that are not coders. In particular, artists are well known in the Wesnoth community for being very sensitive about criticism and our community is used to people being sensitive to critics.

We will try to choose students that accept criticism and are able to filter constructive criticism from useless one. The Wesnoth developer community is used to judging people according to these criteria and the special title we are going to give to applicants will allow us to easily spot any such problems and discuss them before they grow out of control.

If a student disappears, their mentor will be in charge of recontacting the student to see what is going wrong (available time, tension with other developers, with members of the community etc...). Depending on the actual problem, the mentor and the student will have to agree on possible ways to defuse the problem.

If a student disappears completely and there is no way to get back to them, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have SVN write access, so most of the work will be committed either to trunk or to a specific branch) and find a core developer to take on the job. This will probably be slower and less effective for the project, but it's the best we can do.

==== What is your plan for dealing with disappearing mentors? ====
All our mentors are long time developers that volunteered for the job, so we don't expect that to happen. We observed in 2008 the amount of time required to mentor, and our mentors accepted the job knowing the amount of work it involved. Most of them were mentors last year too.

However, should it happen, we would continue to mentor as a developer community the student until we find a new "official" mentor to take on the job.

==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====
Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two (non trival) patches... you're in". With other words, anybody that is able to get two non-trivial patches applied is offered commit privileges.
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our EasyCoding pages [1] (these projects are usually a couple of hours long and hve been chosen to provide easy access to the respective area of code).

Usually, patches go back and forth a couple of times, to make sure that all secondary things are in place (indenting, coding style, modified buildfiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to keep our project alive.

If the student is proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

In 2008 and 2009 all students that were accepted (and a couple more) managed to have commit access before the start of the coding phase. We consider that this policy was successful and we plan to keep it this year.

We also plan to give a special forum title to any students. This will allow all forum members to tell them apart from normal users and give them read/write access to the developer only forums. This will also allow us to quickly spot any problem they might have interacting with the player community. We have a very mature developer community, but our player community is made of all sort of people of all age and education, and it can sometimes be rough.

[1] http://wiki.wesnoth.org/EasyCoding

==== If you are a small or new organization applying to GSoC, please list a larger, established GSoC organization or a Googler that can vouch for you here. ====

==== If you are a large organization who is vouching for a small organization applying to GSoC for their first time this year, please list their name and why you think they'd be good candidates for GSoC here: ====
* Darktable:
Darktable (see http://darktable.sourceforge.net/ and https://sourceforge.net/apps/trac/darktable/wiki/GSOC) is an open source raw development tool.

There are currently no major open source raw development tools. Multiple tools cover the need (ufraw, rawtherapee etc...) but most of them are targeting technical users with interest in photography or signal processing experts rather than "normal" photographer.

Darktable has a very good UI designed around what most photographers expects. It is also a project which is at this interesting stage where there is a solid infrastructure and it needs developer to do the fun part of adding new feature. This is the stage of a project which is the most interesting for developers to join.

The Darktable development community is rather small (3 active developers plus occasional contributors). It could use the extra manpower but is large enough to mentor a student into a core developer pretty fast.

Chances of a student finding it interesting are high, chances of the student bringing major contributions to the project are very high

* Unknown Horizons:
Unknown Horizons (http://www.unknown-horizons.org/) is a 2D realtime strategy simulation with an emphasis on economy and city building.

This is a smaller open source game project with a really dedicated core team of developers. During our talks with the dev who wants to work as admin it was easy to see that they do think about what they do and got some well working infrastructure. Even though the team is rather small at the moment, they are well suited to handle some students and the project has a proven record of being able to actually release something and continue working on the code. Beside their abilities it is always good to support open source gaming, especially when it comes to rather underrepresented areas like real time strategy games.

==== Anything else you'd like to tell us? ====
There is nothing more to say.

==== Backup Admin (Link ID): ====
noy

==== Admin Agreement: ====
(some terms of service by Google that have to be agreed upon)

SoC Ideas Sprite Sheets2011

2011-03-08T20:53:42Z

SkeletonCrew: idea update

{{Template:SoC2011Idea}}
= Submitted proposals: =

{{#dpl:
|resultsheader=''There are %PAGES% submitted student proposals for this idea''
|oneresultheader=''There is 1 submitted student proposal for this idea''
|suppresserrors=true
|noresultsheader=''There are no submitted student proposals for this idea''
|category=Summer of Code 2011 Student Page&SoC Ideas Sprite Sheets2011
|notcategory=SoC 2011 Not Submitted To Google
|include=#Description
|mode=userformat
|format=,, See [[%PAGE%|%TITLE%]] for more information. ,
}}

= Description =
<h2>Allow wesnoth to support spritesheets</h2>
Page for the idea: [[SoC_Ideas_Sprite_Sheets2011]]

Currently, all the Wesnoth unit animations are based on thousands of small png
images, each image representing the unit in a single pose. For terrains the
situation is the same, it has a base image with a lot of transitions to other
terrains, which are now stored as seperate images.

In a sprite sheet approach, each unit is represented by a single, huge, image
where all the unit images are put on a mosaïc pattern and the game knows where
to look for a given image.

The advantage of having a large image with all positions is that it's more
efficient in memory. Also one large file is more effecient on the harddisk and
faster to load than a lot of smaller files. So the change to spritesheets will
have a lot of advantages.

Regarding the implementation the student is free to come up with his/her own
solution and discuss that with the developers during the application period.

= Additional Information =
* How to build those huge sheets from our current images set?
* Wesnoth does not have a fixed number of frames per unit, nor does it have a fixed size for each unit frame. A naïve approach to the problem will not work.

= Whom to bug about this =

SoC Ideas Sprite Sheets2011

2011-02-26T10:01:22Z

SkeletonCrew: Add sprite sheet GSoC idea

{{SoC2011Idea}}
=Additional Information=

Currently, all the Wesnoth unit animations are based on png images, each
image representing the unit in a single pose. In a sprite sheet approach,
each unit is represented by a single, huge, image where all the unit images
are put on a mosaïc pattern and the game knows where to look for a given
image.

The sprite sheet approach has huge gains in term of memory consumption, but
there are a couple of problems that need to be solved

* How to build those huge sheets from our current images set?
* Wesnoth does not have a fixed number of frames per unit, nor does it have a fixed size for each unit frame. A naïve approach to the problem will not work.

SoC Ideas Schema Validation2011

2011-02-26T09:55:47Z

SkeletonCrew: Readd the template removed in the previous commit

{{SoC2011Idea}}
= SoC Ideas Schemes =

Sirp/Dave already added schemes to Frogatto [1](another project he's working
on). This game is also based on WML but not entirely the same as Wesnoth.

Mordante added a comment based, scheme like documentation[2] to the new
widget code which he uses to generate wiki pages [3] with a small python
tool [4]. For the GCI 2010 project several improvements to the tool have
been made to support other parts of WML as well. This tool is a glorified
regex, for this task it will probably not suffice and needs to be a real
parser.

The student will work on a comment based scheme definition that will be
stored in the source code and extracted into scheme files. The current tool
needs to be rewritten or extended and the current comments need to be
changed to store information regarding validation.

The schemes will first be implemented for the new gui since that code
already has some validation and already has quite a bit of comment. The gui
engine also uses its own loading code which makes implementing the
validation easier. Once that has been done more of the current engine will
be converted.

The following demands are on the schemes :
* Needs to be comment style in the source.
* Use an extractor tool to generate the actual scheme files.
* Use an extractor tool to generate wiki documentation.
* Need to validate the WML and give useful error messages (the target audience are average users and not programmers)

[1] http://www.frogatto.com/ 
[2] http://www.wesnoth.org/devdocs/canvas_8cpp-source.html 
[3] http://wesnoth.org/wiki/GUICanvasWML 
[4] http://wiki.wesnoth.org/Wiki_grabber

SoC Ideas Schema Validation2011

2011-02-26T09:53:50Z

SkeletonCrew: Update the page for this year's submission

= SoC Ideas Schemes =

Sirp/Dave already added schemes to Frogatto [1](another project he's working
on). This game is also based on WML but not entirely the same as Wesnoth.

Mordante added a comment based, scheme like documentation[2] to the new
widget code which he uses to generate wiki pages [3] with a small python
tool [4]. For the GCI 2010 project several improvements to the tool have
been made to support other parts of WML as well. This tool is a glorified
regex, for this task it will probably not suffice and needs to be a real
parser.

The student will work on a comment based scheme definition that will be
stored in the source code and extracted into scheme files. The current tool
needs to be rewritten or extended and the current comments need to be
changed to store information regarding validation.

The schemes will first be implemented for the new gui since that code
already has some validation and already has quite a bit of comment. The gui
engine also uses its own loading code which makes implementing the
validation easier. Once that has been done more of the current engine will
be converted.

The following demands are on the schemes :
* Needs to be comment style in the source.
* Use an extractor tool to generate the actual scheme files.
* Use an extractor tool to generate wiki documentation.
* Need to validate the WML and give useful error messages (the target audience are average users and not programmers)

[1] http://www.frogatto.com/ 
[2] http://www.wesnoth.org/devdocs/canvas_8cpp-source.html 
[3] http://wesnoth.org/wiki/GUICanvasWML 
[4] http://wiki.wesnoth.org/Wiki_grabber

SoC Ideas Schema Validation2011

2011-02-26T09:37:09Z

SkeletonCrew: Copy paste from the old idea

{{SoC2011Idea}}
[edit] SoC Ideas Schemes

Sirp/Dave already added schemes to frogatto [1](another project he's working on). This game is also based on WML but not entirely the same as Wesnoth.

Mordante added a comment based, scheme like documentation[2] to the new widget code which he uses to generate wiki pages [3] with a small python tool.

The student will work on a comment based scheme definition that will be stored in the source code and extracted into scheme files. Preferably the scheme definition will be based on Mordante's work.

The schemes will first be implemented for the new gui since that code already has some validation and already has quite a bit of comment. The gui engine also uses it's own loading code which makes implementing the validation easier. Once that has been done more of the current engine will be converted.

The following demands are on the schemes :

* needs to be comment style in the source
o use an extractor tool to generate the actual scheme files.
o use an extractor tool to generate wiki documentation.

* Need to validate the WML and give useful error messages (the target audience are normal persons not programmers)

[1] http://code.google.com/p/frogatto/
[2] http://www.wesnoth.org/devdocs/canvas_8cpp-source.html
[3] http://wesnoth.org/wiki/GUICanvasWML

Fosdem2011

2011-02-01T21:28:01Z

SkeletonCrew: /* Wesnoth Hacking Room */ Add my power outlets to the list

== General information ==
This page is meant to somehow coordinate the small Wesconf taking place at FOSDEM 2011. That is everyone attending should please list him/herself in the list of arrivals and stuff like this. FOSDEM 2011 will take place at the first weekend in Febuary 2011, on Saturday 5th and Sunday 6th.

* Fosdem - http://fosdem.org/2011/

== Schedule/Plans ==
{| border="1" width="100%"
|-
! (nick)name(s)
! Arrival
! Departure
! Accomodation
|-
| AI
| Fri, 4th
| Sun, 6th
| 2go4, booked by Ivanovic, 4-bed room
|-
| Boucman
| Fri, 4th
| Sun, 6th
| 2go4, booked
|-
| Crab_
| Fri, 4th
| Sun, 6th
| 2go4, booked
|-
| elias
| Fri, 4th (airport arrival 12:15)
| Sun, 6th
| BestWestern, booked
|-
| fendrin
| Fri, 4th
| Sun, 6th
| 2go4, booked by Ivanovic, 4-bed room
|-
| grzywacz
| Fri, 4th
| Sun, 6th
| 2go4, booked
|-
| Ivanovic & chrber
| Fri, 4th, "afternoon" (~15:00 at "schokopolis")
| Sun, 6th, leaving right from ULB campus
| 2go4, booked by Ivanovic, 4-bed room
|-
| mordante
| Fri, 4th
| Sun, 6th
| 2go4, booked by Ivanovic, 4-bed room
|-
| Sirp & Dragonking
| Fri, 4th, late afternoon
| Mo, 7th
| Novotel Grand Palace
|-
| thespaceinvader
| Fri, 4th, 1733 Bruxelles Midi
| Sun, 6th, 1649 Bruxelles Midi
| 2go4, booked
|-
| YogiHH
| Fri, 4th, (~18:00 in town center)
| Sun, 6th (?)
| some hotel...
|-
|}

For accomodations please keep in mind that parking in the center of Brussels is really problematic. It might make sense to drive to the University where FOSDEM takes place, park there and take the bus into the town center (where some of the hotels/hostels are).

Possible hostels that we at least contacted over the last years (some of them might already be booked out by now!):
* [http://www.chab.be/ CHAB]
* [http://www.2go4.be/ 2go4] Note: groups bigger 6 are not allowed, so we can (officially) not form a complete Wesnoth group at this hostel, got to meet somewhere in town/at the university...
* [http://www.jeugdherbergen.be/brusselE.htm Bruegel YH]

On the official FOSDEM page [http://www.fosdem.org/2011/practical/accommodation some more possible hotels/hostels] are listed.

== Maps ==
* [http://tinyurl.com/3a65gr Bruegel YH]
* [http://tinyurl.com/35br9c Brussels Central (Train Station) → Bruegel YH]
* [http://tinyurl.com/37d9v4 Bruegel YH → Brussels Central (Train Station) → Novotel Grand Place]
* [http://tinyurl.com/2mzns6 Novotel Grand Place]
* [http://tinyurl.com/3dggg3 CrownePlaza (Europa)]
* [http://tinyurl.com/36epxj FOSDEM]
* [http://tinyurl.com/2w4bms Novotel Grand Place -> FOSDEM]

== Transportation ==
Information about how to reach the FOSDEM is listed at the [http://www.fosdem.org/2011/transportation official transportation subpage].

Short version of how to get there for those that reside in Bruegel YH and Novotel Grand Place (basically town center):

* Enter Bus 71 (Debrouckere - Central Station ("Gare Centrale") - Delta) somewhere at 'Central Station'
* Leave the bus at "ULB" (crossroads Ave. Adolphe Buyl - Sq. Deveze)
* Walk down Ave. Paul Heger on your right hand.

== Wesnoth Hacking Room ==

Wesnoth will not have a room of its own. Instead we will use one of the "general hacking rooms". So far it is not sure which room it will be, if we do it like the last three years, it will be room number 115 in the building AW1. Last year this was the smaller of the two hacking rooms and we had no real problem with conquering (and holding) the first row in this room. There were not too many power outlets, so this year at least Ivanovic will bring one multi-outlet power strip plus some extension cable (5m or something like this). Mordante will also bring a multi-outlet power strip and a 20m extension cable. There is no wired network, everything wireless (and sometimes rather/very unstable!). Beside this you should bring laptops since there are no computers available for hacking.

Short version:
AW1 - Room 115

== Planned discussion ==
We usually discuss all sorts of things at FOSDEM, this section is here to have a small bullet list of things that we actively want to discuss at FOSDEM.
* GSOC 2011: finding mentors, organizing the submission etc..
* GCI 2010/2011: was it good, should we try to do it again next year ?
* FOSDEM 2012 : trying to get a dev room with other games ?
* Wesnoth 1.10: when to release? How to go on?
* Licensing: How should we handle things like the "appstore problem"?
* [wanted: discussion topics!]

== Group Picture ==

to be linked here after FOSDEM

== FOSDEM 2010 ==
We were already at FOSDEM 2010, here something as reference:

* [http://www.wesnoth.org/wiki/Fosdem2010 FOSDEM 2010 wiki page]

== FOSDEM 2009 ==
We were already at FOSDEM 2009, here something as reference:

* [http://www.wesnoth.org/wiki/Fosdem2009 FOSDEM 2009 wiki page]

== FOSDEM 2008 ==
We were already at FOSDEM 2008, here something as reference:

* [http://www.wesnoth.org/forum/viewtopic.php?p=283649#p283649 Forum topic (with group photo)]
* [http://www.wesnoth.org/wiki/Fosdem2008 2008 wiki page]
* [https://mail.gna.org/public/wesnoth-dev/2008-02/msg00078.html Summary of FOSDEM 2008 results]

[[Category:Development]]
[[Category:Wesconf]]

Fosdem2011

2010-12-19T17:53:58Z

SkeletonCrew: /* Schedule/Plans */ add myself to the list

== General information ==
This page is meant to somehow coordinate the small Wesconf taking place at FOSDEM 2011. That is everyone attending should please list him/herself in the list of arrivals and stuff like this. FOSDEM 2011 will take place at the first weekend in Febuary 2011, on Saturday 5th and Sunday 6th.

* Fosdem - http://fosdem.org/2011/

== Schedule/Plans ==
{| border="1" width="100%"
|-
! (nick)name(s)
! Arrival
! Departure
! Accomodation
|-
|-
| Ivanovic & chrber
| Fri, 4th
| Sun, 6th
| 2go4, not booked yet
|-
|-
| Boucman
| Fri, 4th
| Sun, 6th
| 2go4, not booked yet
|-
|-
| thespaceinvader
| Fri, 4th or Sat, 5th
| Sun, 6th
| 2go4, not booked yet
|-
|-
| AI
| Fri, 4th
| Sun, 6th
| 2go4, not booked yet
|-
|-
| mordante
| Fri, 4th
| Sun, 6th
| 2go4, not booked yet
|-
|}

For accomodations please keep in mind that parking in the center of Brussels is really problematic. It might make sense to drive to the University where FOSDEM takes place, park there and take the bus into the town center (where some of the hotels/hostels are).

Possible hostels that we at least contacted over the last years (some of them might already be booked out by now!):
* [http://www.chab.be/ CHAB]
* [http://www.2go4.be/ 2go4] Note: groups bigger 6 are not allowed, so we can (officially) not form a complete Wesnoth group at this hostel, got to meet somewhere in town/at the university...
* [http://www.jeugdherbergen.be/brusselE.htm Bruegel YH]

On the official FOSDEM page [http://www.fosdem.org/2011/practical/accommodation some more possible hotels/hostels] are listed.

== Maps ==
* [http://tinyurl.com/3a65gr Bruegel YH]
* [http://tinyurl.com/35br9c Brussels Central (Train Station) → Bruegel YH]
* [http://tinyurl.com/37d9v4 Bruegel YH → Brussels Central (Train Station) → Novotel Grand Place]
* [http://tinyurl.com/2mzns6 Novotel Grand Place]
* [http://tinyurl.com/3dggg3 CrownePlaza (Europa)]
* [http://tinyurl.com/36epxj FOSDEM]
* [http://tinyurl.com/2w4bms Novotel Grand Place -> FOSDEM]

== Transportation ==
Information about how to reach the FOSDEM is listed at the [http://www.fosdem.org/2011/transportation official transportation subpage].

Short version of how to get there for those that reside in Bruegel YH and Novotel Grand Place (basically town center):

* Enter Bus 71 (Debrouckere - Central Station ("Gare Centrale") - Delta) somewhere at 'Central Station'
* Leave the bus at "ULB" (crossroads Ave. Adolphe Buyl - Sq. Deveze)
* Walk down Ave. Paul Heger on your right hand.

== Wesnoth Hacking Room ==

Wesnoth will not have a room of its own. Instead we will use one of the "general hacking rooms". So far it is not sure which room it will be, if we do it like the last three years, it will be room number 115 in the building AW1. Last year this was the smaller of the two hacking rooms and we had no real problem with conquering (and holding) the first row in this room. There were not too many power outlets, so this year at least Ivanovic will bring one multi-outlet power strip plus some extension cable (5m or something like this). There is no wired network, everything wireless (and sometimes rather/very unstable!). Beside this you should bring laptops since there are no computers available for hacking.

Short version:
AW1 - Room 115

== Planned discussion ==
We usually discuss all sorts of things at FOSDEM, this section is here to have a small bullet list of things that we actively want to discuss at FOSDEM.
* GSOC 2011: finding mentors, organizing the submission etc..
* GCI 2010/2011: was it good, should we try to do it again next year ?
* FOSDEM 2012 : trying to get a dev room with other games ?
* [wanted: discussion topics!]

== Group Picture ==

to be linked here after FOSDEM

== FOSDEM 2010 ==
We were already at FOSDEM 2010, here something as reference:

* [http://www.wesnoth.org/wiki/Fosdem2010 FOSDEM 2010 wiki page]

== FOSDEM 2009 ==
We were already at FOSDEM 2009, here something as reference:

* [http://www.wesnoth.org/wiki/Fosdem2009 FOSDEM 2009 wiki page]

== FOSDEM 2008 ==
We were already at FOSDEM 2008, here something as reference:

* [http://www.wesnoth.org/forum/viewtopic.php?p=283649#p283649 Forum topic (with group photo)]
* [http://www.wesnoth.org/wiki/Fosdem2008 2008 wiki page]
* [https://mail.gna.org/public/wesnoth-dev/2008-02/msg00078.html Summary of FOSDEM 2008 results]

[[Category:Development]]
[[Category:Wesconf]]

AssetLocalization

2010-09-29T21:18:40Z

SkeletonCrew: /* BfW Logo */ add a remark about the maximum size

Being a game, Wesnoth's graphics data carries higher significance than it would in utilitarian software. An image containing English text in an otherwise native language environment, may bite at user's immersion. For example, a mismatch between geographical names in translated text and on maps (like "Blackwater Port", "Ford of Abez", etc.) will certainly not improve user's feeling of completeness of localization effort.

To offset this, a willing translator can also localize images into the world of Wesnoth.

== How Does It Work? ==

Quite not unlike with text. Most text appearing in Wesnoth is up for translation, but given language's translators may leave some untranslated -- either deliberately (i.e. just copying English original), or because they didn't get to it yet. Likewise with the images: any can be localized, but none needs be; if there is no localized version of a given image, the user is presented with the original one. The only difference between text and images is that, unlike text, very few images possibly need to be localized -- presently, about 30 in total.

Once the localized image is made, putting it to work is simple. If the path of the original image in the source tree is:

foo/bar/baz/image.png

then the localized image should be put in:

foo/bar/baz/l10n/ll/image.png

where <tt>ll</tt> is the given language's code, like that used for names of PO files (e.g. <tt>de</tt>, <tt>pt_BR</tt>, etc.) That's it.

Before trying to test any localized images at runtime, it is also necessary that the following message in <tt>wesnoth-lib</tt> catalog is properly translated:

#. TRANSLATORS: This is the language code [...]
#: src/image.cpp:342
msgctxt "language code for localized resources"
msgid "en_US"
msgstr ""

The translation should basically be the same language code as used in paths of localized images (<tt>ll</tt> from the example above), but read the longer explanation in comments of this message for other possibilities.

A tracker script is run periodically on the repository to indicate that localized images need updating when the original image has been changed or moved. There is a file named <tt>l10n-track</tt> in the root of the source tree, which tracks the state for every localized image, grouped by language:

# ll
ok ¦foo/bar/baz/l10n/ll/image.png¦ ea9d6...563ad 30544
...

In each non-comment line, the first field is the state of the localized image, the second the path, third the checksum of the original image, and fourth the revision ID of the original image. When the original image has been modified, the corresponding localized image's state will change to <tt>fuzzy</tt>:

# ll
fuzzy ¦foo/bar/baz/l10n/ll/image.png¦ ea9d6...563ad 30544

If the original image is removed or renamed, the localized one will be marked as <tt>obsolete</tt>:

# ll
obsolete ¦foo/bar/baz/l10n/ll/image.png¦ ea9d6...563ad 30544

Translators should regularly check the <tt>l10n-track</tt> file, making the needed modifications to fuzzied images and submitting new versions (<tt>obsolete</tt> state will probably never be seen, as translation coordination team will see to it that localized images are moved and removed following the original). See below for a quick guide at dealing with fuzzy images. A fuzzy localized image will not be used at runtime, so that users will see the original image -- just like with fuzzy messages in PO files.

Translators can send new and updated localized images to Chusslove Illich <caslav.ilic@gmx.net> or to Espreon <Majora700_at_gmail_dot_com> for committing to the repository. They can also send in any source material used to create the final images, like Gimp XCF files, so that they are easily available for future editing. Source images for given language are located in the <tt>branches/resources/image-localization/ll</tt> directory in the repository.

The technicalities are thus rather simple, the main challenge instead is how to create the localized out of the original images in the first place. This depends on the type of the image: from trivial screenshots, to the more complex Wesnoth logo. Most of the rest of this article will deal with this.

=== Overlay Images ===

A special kind of localized image is an ''overlay'' image -- one which does not simply replace the original, but is combined with it at runtime, overlaying the original content. Of course, the overlay image should have some transparent regions, through which the original content will show up. The overlay image is indicated by adding <tt>--overlay</tt> suffix to its original name:

foo/bar/baz/l10n/ll/image--overlay.png

Overlay images are used purely to avoid needlesly growing the size of Wesnoth packages, in cases when the full image is rather large and only small parts of it need localization. This is typical of maps.

=== Resolving Fuzzy Images ===

When a localized image got fuzzy due to changes to the original, it is necessary to ascertain what is it exactly that had been changed, between the point when the localized image was made and current state. To do this, enter the root directory of appropriate branch in the repository, and observe the fuzzy entry in <tt>l10n-track</tt>:

fuzzy ¦foo/bar/baz/l10n/ll/image.png¦ ea9d6...563ad 30544

The final piece of data here is the revision ID of the original image at the time when the localized image was made. Recover this revision of the original, and copy it with a suffix to current working directory (note omission of <tt>/l10n/ll</tt> from the path):

$ svn up -r 30544 foo/bar/baz/image.png
U foo/bar/baz/image.png
Updated to revision 30544.
$ cp foo/bar/baz/image.png image-30544.png

Now do the same with the current original image (no revision ID necessary in <tt>svn</tt> command line):

$ svn up foo/bar/baz/image.png
U foo/bar/baz/image.png
Updated to revision 39066.
$ cp foo/bar/baz/image.png image-39066.png

After this, current working directory will contain the old and new original, named <tt>image-30544.png</tt> and <tt>image-39066.png</tt>. Now they can be quickly switched between in an image viewer, and the eye will easily capture the differences. There are also tools which can, given two images, produce a graphical diff of some sort.

After the differences have been observed, the localized image can be updated accordingly and submitted again.

== List of Images for Localization ==

An up-to-date list of images ''possibly'' needing localization is given here, and updated as people spot any new such image. Here, "possible" means judged such by at least one translator. Those are typically images containing some English text, but depending on the particular text, many languages may also like to keep it as in English (e.g. "Weldyn").

* In-game images:

images/misc/logo.png
data/core/images/misc/logo.png
-- The BfW logo, visible in the main menu, loading screens,
and elsewhere (both files are same)

data/core/images/maps/wesnoth.png
-- Wesnoth's main map, in the background of the main menu
and as the main map in some campaigns

data/core/images/help/hpxp.png
data/core/images/help/recruit.png
data/core/images/help/tooltip.png
-- screenshots in the help sections

data/campaigns/An_Orcish_Incursion/images/an-orcish-incursion-map.png
data/campaigns/Dead_Water/images/Background_Map.png
data/campaigns/Descent_Into_Darkness/images/misc/descent-into-darkness.png
data/campaigns/Eastern_Invasion/images/eastern-invasion-map.png
data/campaigns/Legend_of_Wesmere/images/legend-of-wesmere-map.png
data/campaigns/Liberty/images/maps/liberty-map.png
data/campaigns/Son_Of_The_Black_Eye/images/farnorth.png
-- main maps of respective campaigns

data/campaigns/The_Rise_Of_Wesnoth/images/story/trow-logo.png
data/campaigns/The_Rise_Of_Wesnoth/images/story/east.png
data/campaigns/The_Rise_Of_Wesnoth/images/story/west.png
data/campaigns/The_Rise_Of_Wesnoth/images/story/tgi-blackmore.png
data/campaigns/The_Rise_Of_Wesnoth/images/story/tgi-clearwater.png
data/campaigns/The_Rise_Of_Wesnoth/images/story/tgi-jevyan.png
data/campaigns/The_Rise_Of_Wesnoth/images/story/tgi-southbay.png
data/campaigns/The_Rise_Of_Wesnoth/images/story/tgi-stormvale.png
data/campaigns/The_Rise_Of_Wesnoth/images/story/tgi-thegreenisle.png
-- text overlays in the TRoW campaign

data/core/images/lobby/sort-az.png
data/core/images/lobby/sort-az-off.png
-- sorting icons in multiplayer lobby (with "A-Z" on them)

* Images in the manual:

doc/manual/images/game-screen.jpg
doc/manual/images/main-menu.jpg
doc/manual/images/multiplayer.jpg
doc/manual/images/recruit.jpg
doc/manual/images/right_pane.jpg
doc/manual/images/top_pane.jpg

If you come across an image eligible for localization and not listed here, please add it.

== Creating Localized Images ==

This section gives brief, but hopefully sufficient instructions on how to produce localized images, by each distinct type. Note that there is a balance between simplicity of instructions and quality of final images -- whenever you can do better than describe here, do not hesitate.

Most of the time it will be necessary to edit an image template using a general image manipulation app, and the instructions here will be presented with [http://www.gimp.org/ Gimp], a popular and free tool for this purpose. There is also a [[#Gimp For Translators|section of this article]] describing some of the Gimp's features frequently used in present context.

=== Screenshots ===

Screenshots in the game are found on the help pages. Instead of full game screens, they are usually only smaller portions of screens. Making localized versions of these images is naturally easy, one just needs to grab some screenshots from the localized version of the game. Just a few points:

* Screenshots should be captured from the game running at 1024×768 resolution.

* To grab a screenshot, it's probably easiest to run the game in window instead of full screen, and use whatever screenshot capture utility available. (Gimp too can be used, menu '''File→Create→Screenshot'''.)

* The screenshot should be saved in PNG format (the capture utility will probably provide various formats).

* If the capture utility didn't provide option to select part of the screen to capture, to reduce the screenshot to the required small portion of the screen Gimp's cropping tool can be used ('''Tools→Transform Tools→Crop''').

* It is not necessary for the dimensions of localized screenshot to be exactly the same as the original screenshot, but should be near.

((to be done: screenshots in the manual; describe the explicit <tt>image-x.y.z.jpg</tt> versioning system))

=== BfW Logo ===

The sworded shield logo with "The Battle for Wesnoth" text is shown on loading screens and at the head of the main menu, thus being the foremost target for localization (for languages which have translated the game's name, of course). Here are the steps to create the localized logo with Gimp. Note in order to make sure the logo fits properly in the title screen it shall not be larger as 550x250.

Fetch the template logo from here:

http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/templates/bfw-logo/bfw-logo.xcf

There is just one layer in the file, <tt>shield</tt>, with the sworded shield on transparent background and without any text. Rename the file to e.g. <tt>bfw-logo-LANG.xcf</tt>, to work on it and keep it as "source" of your localized logo.

Pick a font in which you would like to write the logo text. The English logo uses "Celtic Garamond the 2nd" font, easily found by Google for free download, as the starting point. This font, however, contains only English letters (not even Western European), so some creativity may be needed to make use it. One could, for example, manually add any diacritics (copied over from suitable letters of another font). Another option is to simply use another font, which both has the glyphs of required characters, and is somewhat fantasy-looking.

The hardest part of localizing the logo is that of producing a single-color version of the text of translated game name. This may seem surprising at first -- why not just use the text tool to write out the text in proper size, and be done with it? The problem with this is that, as a rule rather than exception, the letters will not be mutualy spaced in visualy pleasing manner. For each font size, the spacing between any two paired letters needs to be manualy adjusted, a process which is called ''kerning''. Only high quality fonts have kerning instructions built in, and then usually only for small font sizes. Therefore we have to perform kerning manually.

Create a layer named <tt>text-temporary</tt> with transparent background (menu '''Layer→New Layer...''', type the name, and make sure '''Transparency''' is selected as '''Layer Fill Type'''). Switch to this layer, select text tool ('''Tools→Text'''), make sure that options '''Hinting''', '''Force auto-hinter''', and '''Antialiasing''' are all selected, and set color to black and font size to 42 (this size is appropriate for Celtic Garamond font mentioned above, may be different for another font). Write out the text with ''a space between each two letters'', i.e. like "B a t t l e ...". At this point, do not bother about text being centered over the shield; in fact, it is best to make the shield layer invisible (visibility of layers is controlled through the leftmost column in layer view).

If the name starts with a definite article (''The'', ''La'', etc.), put the article above the main text, as in the English logo -- of course, only if such splitting is permitted by title style in your language. This means once more applying the text tool to write out the article, also with a space between each two letters, and with font size 32.

Text written out with the text tool will appear as another, special layer. Convert it to ordinary layer using '''Layer→Discard Text Information'''. Make sure this new layer is positioned just above <tt>text-temporary</tt> (layer order is shown in the layer view, and can be changed with up/down arrows at the bottom), that the new layer is selected, and execute '''Layer→Merge Down'''. The new layer will dissapear and the text will become part of <tt>text-temporary</tt> layer. (In case there was another piece of text for the definite article, repeat the same procedure for it.) If Celtic Garamond font was used, to finally get to letter size quite near to English logo, resize <tt>text-temporary</tt> layer ('''Layer→Scale Layer...''') to 80% by horizontal and 120% by vertical.

At this point, for example, the image with translated name "Boj za Vesnot" will look like this:

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/text-temporary.jpg</center>

(The <tt>shield</tt> layer has been dimmed by setting it's opacity to 50%, using the top slider in layer view. This is useful whenever a layer is not the focus of current operations, but may be needed for orientation.)

In preparation for kerning, each letter needs to be put on its own layer. To do this for a given letter, make <tt>text-temporary</tt> current layer, use rectangle selection tool ('''Tools→Selection Tools→Rectangle Select''', or just press '''R''' on keyboard), select the letter with generous empty space around it (this should be easy, since letters are widely spaced), and cut and paste the selection; this will create a floating selection layer, which can be turned into a normal layer by double-clicking on its name in layer view and renaming it to the letter itself (possibly with a suffix like <tt>-2</tt> for letters appearing more than once). Repeat this until all letters are on their own layers. It is best to start from the last letter in the name and go backwards, because then the letter layers are going to end up nicely ordered in the layer view (but they can always be ordered manually afterwards). When doing cut and paste step, it is critical that all the pasted letters appear at the same vertical position on the image (for this, fix the rectangle height on the preferences and position each rectangle at a fixed chosen vertical position before cutting). <tt>text-temporary</tt> layer becomes empty after all letters have been processed, so delete it ('''Layer→Delete Layer''').

Letters should now be horizontally moved to obtain visually pleasing spacing. Since each letter is on its own layer, moving single letters is easy. To move more than one letter together, you can link the corresponding layers (by clicking in the second left-most column in layer view, next to visibility column, producing chain-like icon). Layer is moved by the general move tool ('''Tools→Transform Tools→Move''', '''M''' on the keyboard), and to be sure that you are moving it exactly horizontally, observe the offset coordinates in the status bar; also, keeping '''Ctrl''' key pressed will constrain a move to one of eight radial directions, which starts being helpful for moves longer than a few pixels.

Here lays the toughest part: what does it mean "visualy pleasing"? How do you know when the letters and words are spaced "just right"? One way in which you ''cannot'' know this, is by measuring distances on pixel level -- an objective measure here is of no use, as the goal is to achieve perceptual balance for the observer's eye. So, unfortunatelly, you must simply follow your feeling. (See the note at the end of this section for how you should confirm that you have done this, as well as the logo overally, acceptably well.)

When the letters have been positioned, turn on the <tt>shield</tt> layer, link all letter layers, and move them such as to be centered over the shield. For proper vertical centering, follow the English logo.

Outer portions of the image should now be cut off such that the image is only as wide as the centered text, plus about one to two letter widths of empty space on each side. This is done by executing ''''Image→Canvas Size...''. In the dialog, make sure '''Width:''' and '''Height:''' are not linked (break chain icon to the left), and enter the appropriate new width. Click on '''Center''' button to make all layers centered with respect to new image width. In '''Resize layers:''' listbox, select '''Image-sized layers'''. Click '''Resize''' to exit the dialog and resize the image. If you left too much or too little empty space on the sides, you can undo and repeat the operation using a corrected guess for the width.

After the blank text has been created and positioned, the remaining steps to create the final logo are rather automatic.

The only layers in the image should now be letter layers and <tt>shield</tt>. Make <tt>shield</tt> layer invisible and all letter layers visible, and execute '''Layer→New from Visible'''. This will create a new layer containing all the letters; rename it to <tt>text-base</tt>. Do not delete letter layers, as they may be needed later for corrections in spacing, but make them all invisible. Here is how the image should look at this point:

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/text-base-final.jpg</center>

As an example of why manual kerning is necessary, observe how the first word above, "Boj", looks like. If instead you try to write it out directly by the text tool, in Celtic Garamond font, you will see that the letter "o" is stuck to "B" while "j" is visibly separated from "o", resulting in quite ungainly word as whole.

Duplicate the <tt>text-base</tt> layer four times ('''Layer→Duplicate Layer'''), and name the copies as follows, going upwards from <tt>text-base</tt>: <tt>text-map</tt>, <tt>text-outline</tt>, <tt>text-shadow</tt>, <tt>text-final</tt>. Now we'll play a bit with these four layers. Note that for the following steps it is easier to always have only the currently selected text layer visible, while other layers should be hidden.

Switch to <tt>text-map</tt> layer and start Gaussian blur filter ('''Filters→Blur→Gaussian Blur...'''). In there, set both horizontal and vertical blur radius to 5 pixels. The preview pane should show how that the text got quite blurry; click '''Ok''' to apply the blur. Repeat this exact same filter for <tt>text-outline</tt> and <tt>text-shadow</tt> layers (you can just switch to each of them and use '''Filter→Repeat Last''').

Some layers should now get color different from black. Change to <tt>text-final</tt> (the topmost layer, which didn't get blurred), and start '''Colors→Colorize...'''. In the dialog, set hue to 50, saturation to 40, and lightness to 60. As you do this, the text in the image should reflect the modifications, and in the end it should be pale sand-like color. Click '''Ok''' to apply colorization. Change to <tt>text-map</tt> layer (one of the blurred layers), also use '''Colors→Colorize...''', but this time only set lightness to 100. This should make the blurred text white.

Switch to <tt>text-final</tt> and start '''Filters→Map→Bump Map...'''. From the '''Bump map:''' dropdown list in top right corner of the dialog, select the <tt>text-map</tt> layer (the layer name may be somewhat strange and possibly shrinked, so look the small icon to the left for the whitey pattern produced by white text on that layer). Check '''Compensate for darkening''' (should be so by default), and then set the sliders: azimuth 135, elevation 40, depth 10 (rest should be all zero). In the preview pane to the left you should now see the final bevelled text:

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/text-bump-map.png</center>

(By this point, the colors may look not sufficiently near to the original, due to differences between Gimp releases. E.g. in a 2.4.x release the colors were reported too dark, and that additionally executing '''Colors→Brightness-Contrast''', with values 90 and 70 respectively, yielded better result.)

To complete the composition, make sure only the following layers are visible: <tt>shield</tt> (put its opacity back to 100% if it was dimmed), <tt>text-outline</tt>, <tt>text-shadow</tt>, <tt>text-final</tt>. Layers <tt>text-outline</tt> and <tt>text-shadow</tt> provide some dark shade behind the letters, to make them stand out better on the shield. Move both of these layers by single pixel downward; when moving, check '''Move the active layer''' in the move tool options, as otherwise it will be hard to grab the desired layer. The final result should look like this (note the ordering and visibility of layers):

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/shield-w-text-final.jpg</center>

The logo should now be exported as PNG image, named <tt>logo.png</tt>, using '''File→Save a Copy...''' (choose '''Merge Visible Layers''' when asked, default PNG export options will do). But do keep around the original Gimp XCF image, in case some changes are to be made in the future.

'''Note: Having a well done localized logo is very important for the first impression of the game. Therefore, there is a special rule for accepting localized logos: you have to get explicit approval from Wesnoth's art director, Jetrel. He can be contacted through forum PM, and sometimes can also be found on IRC (<tt>#wesnoth-dev</tt> on Freenode).'''

=== TRoW Logo ===

The logo with the "The Rise of Wesnoth" text is displayed on one of the story screens of the first scenario of ''The Rise of Wesnoth''. It is only seen once and is fairly easy to make.

First, fetch the logo from the Subversion repository:

http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/templates/trow-logo/trow-logo.xcf

As with the main logo, the TRoW logo uses "Celtic Garamond the 2nd".

As with the process of creating the main logo, switch to the text tool and enable the following options: '''hinting''', '''force-autohinting''', and '''antialiasing'''. Set the font size to seventy.

As the font size is so large, the text tool should get the spacing right, unlike the smaller text for the logos, so just write out the text one two or three lines (you should only use three lines if the text uses things such as prepositions).

If the text tool did not get the spacing right, then cut up the the letters into different layers and move as necessary.

After writing out the text, align the letters against the letters in <tt>original</tt>, then center the text against the image... like the text in <tt>original</tt>.

After you properly aligned and centered the text, merge all of the layers with the translated text (if there is more than one) and name the layer with all of the translated text <tt>text-base</tt>.

Duplicate <tt>text-base</tt> four times. The order (in ascending order) and names of the layers (including <tt>text-base</tt>) should be like this: <tt>text-base</tt> <tt>text-map</tt>, <tt>text-outline</tt>, <tt>text-shadow</tt>, <tt>text-final</tt>.

Switch to <tt>text-map</tt>; use the '''Colorize''' tool to make the layer all white (set the lighting to one hundred in the colorize dialog).

Now, apply an eight-radius Gaussian blur to <tt>text-map</tt>. Afterwards, apply a five-radius Gaussian blur to <tt>text-outline</tt> and <tt>text-shadow</tt>.

Switch to <tt>text-final</tt>; summon the '''Colorize''' tool; set hue to fifty, saturation to forty, and lightness to sixty; apply the effect. Afterwards, duplicate <tt>text-final</tt>; put this duplicate above <tt>text-final</tt> and call it <tt>text-final lighting</tt>.

Switch to <tt>text-final lighting</tt>; summon the '''Hue-Saturation''' tool; set hue to −165; apply the effect. Afterwards, set the layer mode of <tt>text-final lighting</tt> to "Lighten Only" and set its opacity to thirty percent.

Switch to <tt>text-final</tt>; summon the '''Bump Map''' dialog. Set the map to be bumped (Bump map) to <tt>text-map</tt>; set azimuth to 135, elevation to forty, depth to twenty, and the rest to zero. Make sure that "Compensate for darkening" is checked. Afterwards, apply the effect.

Switch to <tt>text-final lighting</tt>; summon the bump map dialog; keep the same settings we used last time, but check "Invert bumpmap"; apply the effect.

Drag down <tt>text-outline</tt> and <tt>text-shadow</tt> by one pixel.

Now, make sure that only the following layers are visible: <tt>text-outline</tt>, <tt>text-shadow</tt>, <tt>text-final</tt>, and <tt>text-final lighting</tt>.

After doing so, you should have a beautiful logo.

'''Note: Like for the main logo, TRoW logo has to be cleared by Jetrel (see the ending note in main logo section).'''

=== Maps ===

Each campaign comes with a map, where locations of events are highlighted as the scenarios progress. Since these locations are frequently mentioned in narration and character conversations, it may be more than merely a "nice touch" to match the map labels to in-game texts. In particular, the main map of Wesnoth, which is used by several campaigns, also figures as the background of the main menu.

Luckily, most maps derive from the single source within the main repository:

http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/cartography-tools/great-continent.xcf

This Gimp source contains all topography features, as well as, most importantly, textual labels as separate layers. The procedure of localizing a map is thus this: export a PNG image with all the topography of required map, but without any text label, and then add translated labels to it. Here we'll work on the main menu map (<tt>data/core/images/maps/wesnoth.png</tt>) as the example.

The main menu map is assembled out of the following layers, not taking labels into account: <tt>Wesnoth topography</tt>, <tt>Wesnoth Marsh</tt>, <tt>Wesnoth Forests</tt>, <tt>Wesnoth Roads</tt>, <tt>Wesnoth Towns</tt>, <tt>Border</tt>, <tt>Border BG</tt>. Make ''only'' these layers visible, then export them as PNG using '''File→Save a Copy...''' (choose '''Merge Visible Layers''' when asked, default PNG export options will do); name this PNG file <tt>wesnoth-topo.png</tt>. Then, make the topography layer invisible, and make ''only'' the label layers visible: <tt>Wesnoth Human Names</tt>, <tt>Wesnoth early labels</tt>, <tt>Wesnoth late labels</tt>, and export them too as <tt>wesnoth-labels.png</tt>.

Open the previously exported <tt>wesnoth-topo.png</tt>, and immediately save it as ('''File→Save As...''') <tt>wesnoth-LANG.xcf</tt>, where <tt>LANG</tt> is your language code. Note the <tt>.xcf</tt> extension, which means this is now no longer a plain PNG bitmap, but a Gimp XCF image. This will be the source of your localized map, to which you will be able to return to at any later moment (e.g. if a label needs to be changed to reflect updated translation). Change the name of the only layer, <tt>Background</tt>, to <tt>topography</tt>.

Open the previously exported PNG of original labes as a layer with the current image ('''File→Open As Layers...'''). Tha labels will appear over the topography, visually resulting in composition just like the full map in the game. Change the name of the new layer to <tt>original-labels</tt>. This layer serves only as guide to position the translated labels, so set its opacity to 25%-50% (slider at the top of layer view), such that it becomes unobtrusive, yet discernable enough to indicate label positions.

The result so far should look like this:

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/topo-w-orig-labels.jpg</center>

Now we are ready to start placing translated labels. For all labels, keep in mind to place them such that they are approximately covering the original label, as indicated by the dimmed <tt>>original-labels</tt> layer.

As for the font, original labels are written using Monotype Corsiva, which is easy to find for free download. If it does not contain all the glyphs needed for your language, another similar font to try is URW Chancery, which may already be installed by your distribution. If neither works, as usual try to find one that does and has a fantasy look to it.

There are three distinct types of labels on the main map, so let's cover them from easiest to hardest to make.

'''Plain Labels'''

Plain text labels are the most numerous. They are merely properly colored horizontal text, written down directly on the map. Therefore, to make one such label, just use text tool ('''Tools→Text'''), choose font size (13pt is the size for most of the original labels), check all of '''Hinting''', '''Force auto-hinter''', and '''Antialiasing''', click on the place on the map where the label should be, and write out the translated name.

You don't have to hit the desired position for the label exactly at the moment of writing. The label will become a special text layer, named by the text itself, which you can move around using the move tool ('''Tools→Transform Tools→Move'''). Note that you should ''not''' merge this text layer to any other layer, after you have finished positioning it. That way you will always be able to change the text at a later point (by double-clicking on the layer icon in layer view), rather than recreating it anew.

The only slightly tricky bit here is choosing the color for the text. Original labels are not all of same color, but depend on the darkness and tone of the map below it (e.g. whether it is sea or land). To pick a proper color for each label, the easiest is to load the original PNG image (<tt>data/core/images/maps/wesnoth.png</tt>) and use color picker ('''Tools→Color Picker''') to collect colors from each original label in turn. Since letters are antialiased, always pick the darkest color in the label.

Here's a view of one label made like this:

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/map-label-plain.jpg</center>

Note the special text layer "''Glinova šuma''" ("Glyn's Forest") on the right, and how the transparent original label from the <tt>original-labels</tt> layer is showing below the translated one. To have a clear view of the new text, you can switch <tt>original-labels</tt> on and off by cliking on in the left column in layer list.

'''Rotated Plain Labels'''

Some of the plain labels are rotated to match the topographical feature, e.g. a river direction. To make such a label, first make the plain horizontal label as usual. This label now needs to be rotated.

Unfortunately, Gimp cannot currently rotate text layers, so you first need to convert the text to ordinary layer ('''Layer→Discard Text Information'''). Then, to rotate the layer, open '''Layer→Transform→Arbitrary Rotation...''' dialog. Make sure that '''Interpolation:''' field in the tool view (outside of the dialog) is set to '''Cubic'''. In the dialog, move the slider around and observe the image, until the rotation is approximately the same as that of the transparent original label beneath, and click '''Rotate'''. To finally properly position the label, just move its layer to match the original label.

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/map-label-plainrot.jpg</center>

The image above shows the translated "Bay of Pearls" ("''Biserni zaliv''") label, where the rotated label layer is seen to be an ordinary layer, instead of special text layer (with editable text) such as the one for plain labels.

'''Parchment Labels'''

Labels covering forests, mountains, and other features with uneven background, are put on what appears to be a rectangular piece of parchment. Fortunatelly, the source Gimp image for original maps (the one you used to export initial topography), also contains assortment of various labeling parchments, on the <tt>Label Workshop</tt> layer:

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/map-parchments.jpg</center>

The idea then is to copy the appropriate parchment from this layer to the localized image, and then put a plain label above it. The difficulty is that copied parchments cannot be used as-is, but should be cut to the length of text.

First create two layers ('''Layer→New Layer...''') which will contain all the parchments, named <tt>label-parchments</tt> and <tt>label-parchments-woods</tt>, and make them transparent. Place these layers just above the <tt>original-labels</tt> layer, below all text label layers. You will then always copy parchments from the <tt>Label Workshop</tt> layer of the original image, to one of these two layers in the localized image. If a parchment is fully or partly over woods terrain, it is placed on <tt>label-parchments-woods</tt>, and otherwise to <tt>label-parchments</tt>. Set opacity of <tt>label-parchments</tt> to 75% and of <tt>label-parchments-woods</tt> to 90%, to have slightly transparent parchments as in the original.

To produce a parchment label, first write out a plain label over the map feature which should get the parchment background. This will serve to know how to position the parchment, and, more importantly, how to cut the parchment to the appropriate length. A parchment may need to be either extended or shrinked by cutting.

To extend a parchment, cut away right portion of it, and paste it such as to nicely fit around the right end of the text. Then cut the remaining left portion and paste it to fit around left end of the text. There will now be a gap in the parchment, which you should fill out by copying and pasting a mid-portion of the same parchment from the <tt>Label Workshop</tt> layer of the original image. To shrink a parchment, do the similar, only there will be no gap to fill after parts are cut and pasted. To decide where exactly to cut the parchment, check that when image is zoomed to 100%, there are no obvious joining artifacts (no repeating patterns, which brain easily notices).

Here is the translated version of "Grey Woods" label ("''Sivošumlje''"), with one text layer like for a plain label, and the length-cut parchment on the newly created <tt>label-parchments-woods</tt> layer:

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/map-label-parchment.jpg</center>

Once all labels have been translated, make <tt>original-labels</tt> layer invisible, and all other layers visible. Export the final PNG image using '''File→Save a Copy...'''. The name should be the same as the original PNG image, which is <tt>wesnoth.png</tt> for the main map.

=== Overlay Cuts ===

The original image may have quite a heavy file size, while only small portions of it need to be translated. The main menu map is the prime example, with its 1.800 kB file size; if, say, ten languages would localize it and submit as full image, this map alone would make the distributed package grow by 18 megabytes. On the other hand, an image consisting of only the translated labels (with some portion of the map below them), and otherwise mostly transparent, would have about 180 kB. As mentioned [[#Overlay Images|earlier]], the game can overlay such transparent cuts over the original image at runtime, to produce the final localized image.

We'll use the main menu map as the example for producing an overlay cut. Open the localized XCF image of the map, and add one more layer to it, <tt>overlay-mask</tt>, also transparent. Place this layer on the top, and reduce its opacity to 50%. On it, we will draw a plain white rectangle over each translated label, such that it encompasses both the translated label ''and'' the original label (which is visible through semi-transparent <tt>original-labels</tt> layer). To draw a rectangle, use rectangle selection tool ('''Tools→Selection Tools→Rectangle Selection'''), just like when about to copy-paste stuff. But, instead of copying/cutting anything, fill the selection with foreground color (which you should have set to white), using '''Edit→Fill with FG Color'''. This is the result:

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/overlay-mask.jpg</center>

Note that the selection rectangle has enveloped both the original label, "The Great Ocean", and the translated label, ''Veliki okean''. This is necessary in order that when the translated label is smaller than the original, such as in this case, outer sections of the original label do not show through when the localized overlay is composed with the original image.

You can of course use any of the Gimp's drawing tools to create white areas above labels. E.g. rectangle will cover more space than necessary for rotated labels, so there you may want to draw properly aligned lines using the pencil ('''Tools→Paint Tools→Pencil''') with a very thick round brush.

Once you create masks over all translated labels, load the previously exported PNG of the localized map. Copy the <tt>overlay-mask</tt> layer from the XCF to the PNG image, by dragging it from the layer view of the XCF to the image area of the PNG. ''Do not'' save the PNG image at that point, nor during any of the following steps; it should remain the ordinary, full localized image.

Select the <tt>overlay-mask</tt> layer just copied into the PNG (in fact, it will be named <tt>overlay-mask copy</tt>, and the only other layer should be <tt>Background</tt>) and execute '''Layer→Transparency→Alpha to Selection'''. This will create a selection out of the overlay layer:

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/overlay-layer-to-mask.jpg</center>

What remains to be done is straightforward. Without removing the selection, make <tt>overlay-mask</tt> layer invisible, switch to the <tt>Background</tt> layer, execute '''Select→Invert''', execute '''Edit→Delete''', and the overlay cut is complete:

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/overlay-final.jpg</center>

Save it as <tt>wesnoth--overlay.png</tt>, where <tt>--overlay</tt> ending is needed for the game to recognize that the image is not standalone, but an overlay. You should save the XCF image with <tt>overlay-mask</tt> layer, rather than discarding it, so that at a later point you can modify the mask and repeat the few steps above to create the overlay cut (e.g. when translation of a label is changed).

== Gimp For Translators ==

Being a general-purpose bitmap-editing tool, beginners' tutorials on Gimp usually assume that the reader wants to go from the basics towards becoming a proficient Gimp user one day. This, however, provides too much breadth for the limited scope of retouching images for localization, as we are doing in this article. Of course, if you indeed would like to learn about bitmap editing in general, by all means do go through such tutorials (there are books too) in detail, and then return to this article to apply the obtained knowledge.

If, on the other hand, you'd rather "just get the job done" (such as, for the most part, the initial author of this article), the following subsections shortly explain some crucial elements of Gimp needed to follow the instructions on [[#Creating Localized Images|creating localized images]]. You can also consider them a guideline to what to pay special attention to, if the next thing you do is look for a more in-depth tutorial text.

=== Orientation ===

Here is a downscaled screenshot of what ''may'' pop up when Gimp 2.6 is started (Gimp's layout is highly configurable, so you may see something somewhat different), with most important areas marked with numbered red dots:

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/gimp-windows.png</center>

Gimp uses ''single-document interface'', giving its elements as separate windows, such that they can be manipulated by the mechanisms of the desktop environment on which Gimp is run. For example, under typical Unix desktop environments (KDE, Gnome, etc.), user may want to work with Gimp on a virtual desktop dedicated to it.

Number (1) marks the window which will contain the image, once opened or created a new (it's empty on the screenshot). There will be as many of these windows as there are images opened. (2) is the "toolbox", the collection of icons representing Gimp's basic drawing, selection, transformation, etc. tools. All of them can also be activated from the '''Tools''' menu, and more importantly, by keyboard shortcuts. The two black/white overlapping rectangles at the bottom show the current foreground and background colors. You can select other colors by clicking on them. (3) is the tool options view, where the behavior of currently selected tool can be adjusted. (4) is the ''layer'' view, currently empty as no image is opened (more on layers later). These are just some of many elements of Gimp workspace, those most important to our present needs. If some is missing when you start Gimp on your machine, try turning it on through the '''Windows→Dockable Dialogs''' menu.

Let's now create an image, with ''transparent'' background. Go to '''File→New...''', set width and height to something smaller (e.g. 320×256 pixels), expand '''Advanced Options''', and under '''Fill with:''' select '''Transparency'''. In the image window you should now see a light-dark gray checkerboard pattern, and the layer view should list the <tt>Background</tt> layer.

To paint something on the empty image, select the pencil tool (click on pencil icon in toolbox, select '''Tools→Paint Tools→Pencil''' from the menu, or simply press N on keyboard). In tool options, click right of '''Brush:''' and select a bigger circle from the different brushes. Now simply start painting over the image, by holding left mouse button. Change the foreground color (by clicking on its rectangle in toolbox) to something else, then paint some more. Here's a possible result of this highly precise action we just undertook:

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/gimp-nibblets.png</center>

Of note are the options to the pencil tool on the lower left (e.g. "Circle (19)" selected as brush), and the layers view which shows the single <tt>Background</tt> layer. What's this with layers, anyway?

=== Layers ===

Layers are one of fundamental concepts when working with just about any kind of images and drawings, bitmap or otherwise. Rather then theorizing about it, let us immediately create another layer. Either select '''Layer→New Layer...''' from the menu, click on the blank sheet icon in lower left corner of layer view, or press Ctrl+Shift+N. In the dialog that pops up, set layer name to <tt>Doodle</tt>, make sure '''Transparency''' is selected, and click '''Ok'''. In the layer view you will now see the <tt>Doodle</tt> layer, which will be highlighted and above the <tt>Background</tt> layer.

Repeat fooling around with pencil tool, while making sure that <tt>Doodle</tt> layer is highlighted in the layer view:

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/gimp-nibblets-twolay.png</center>

Note the icons left of layer names in layer view: they reflect the layer content, and it appears that the black and blue lines are on <tt>Background</tt>, while red and white are on <tt>Doodle</tt> layer. This is precisely what had happened, because <tt>Background</tt> layer was the active one (highlighted in layer view) while painting the first time, and the <tt>Doodle</tt> layer while painting the second time.

Yet further left of layer names are "eye" icons, which show that layers are visible. Clicking on them will make layers visible or invisible; observe how the content of respective layer disappears and appears on the image together with switching the visibility. A layer can also be made semi-transparent, rather than completely invisible. Try playing with the '''Opacity:''' slider at the top of layer view while the <tt>Doodle</tt> layer is selected.

You may immediately realize some uses of layers. For example, a text label on a drawing can be added as a separate layer, without irreparably changing the basic drawing, such that it is easy to change the text later on. Layers can also be duplicated with all the content, in order to slightly change one and try which of the two versions better fits with the complete image. And so on. Any realistic image worked on with Gimp will contain at least several layers, and there may easily be tens of them.

Always keep in mind that, same as it happened above with the pencil tool, almost all painting, transforming, colorizing and other operations influence only the currently selected layer (the one highlighted in layer view). An easy oversight to make when there are many layers is to select the wrong layer, or forget to select the desired one, prior to performing an operation. Of course, there's always '''Undo'''.

=== Selection ===

Time to start copying and pasting things around. Same as with text, a portion of image needs to be first ''selected'', to be copied or cut, and then pasted. Unlike as with text, there are many ways in which the selection can be made: just take a look in '''Tools→Selection Tools'''. The basic of those is probably the rectangle selection; to activate it, click on dotted rectangle icon in toolbox, select '''Tools→Selection Tools→Rectangle Select''' from the menu, or press R on keyboard. Before doing anything, make sure <tt>Background</tt> layer is selected.

Left click somewhere on the image and drag the pointer. A translucent rectangle frame will spread from the point of click as you drag the pointer. After releasing the mouse button, the rectangle will become white-black dashed, with dashes moving around (the "marching ants" pattern). By this, you have made a selection (there will also be four smaller rectangles in its corners, which you can use to further adjust the selection sweep). To cancel the selection, without doing anything, just click somewhere outside of it.

Now copy the selection to clipboard, by pressing the usual Ctrl+C, or selecting '''Edit→Copy''' from the menu. Copying itself will not yield any visual effect. The important bits start to occur when you paste the copied selection, by Ctrl+V or '''Edit→Paste'''. Pasted selection will appear at the same place where the original was. There are several things to observe now:

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/gimp-selection-copy-paste.png</center>

* The selection contour will be slightly changed to show exactly what was copied, omitting any transparent regions in the original selection.

* A new layer, named <tt>Floating Selection (Pasted Layer)</tt> has appeared. This is a ''temporary'' layer, which may either be made a permanent layer by selecting '''Layer→New Layer...''', or may be merged into the previously selected layer by canceling the selection (e.g. clicking outside of it). You can move the pasted layer around by left clicking and dragging within it.

* Because you have hit copy when <tt>Background</tt> layer was selected, only the content within selection and on that layer got copied and pasted. You can even make selection while one layer is active, then switch to another, and hit copy to grab the portion of that other layer. Also, while pasting action puts copy on its own temporary layer, canceling the selection will merge it into previously selected layer.

If you turn temporary pasted layer into a permanent layer, you will notice the motionless yellow-black dashed contour. It is also visible in the screenshot above, at sections not covered with moving white-black pattern. This contour shows the layer boundaries, that is, every layer can have its own size independent of the image size. The boundary size of a layer can be adjusted using '''Layer→Layer Boundary Size...'''. Instead of changing boundaries, layer can be resized with all its content using '''Layer→Scale Layer...'''.

You can now explore other ways of making selections (remember, clicking out of selection area while selection tool is active will cancel the current selection). E.g. if you choose '''Tools→Selection Tools→Fuzzy Select''', make <tt>Background</tt> layer active, and click somewhere on the thick blue line in the screenshot above, exactly this entire line will be selected. Every selection tool has some options in the tool view, which may be tweaked to affect exactly what is selected. For the fuzzy selection, for example, one can adjust the color sensitivity ('''Threshold:''' slider) to affect how much big a color difference is used to determine boundaries of selection.

Same as most modification operations affect only the currently selected layer, in presence of selection they also usually affect only the selected area. To test, make a rectangle selection, then switch to pencil tool and try to draw on the image. The pencil will leave trace only within the area of the selection, and on the currently active layer.

=== Text ===

Of the many painting tools, a particularly important one for localizing images will be, naturally, the text tool. It is activated by pressing the big A icon in the toolbox, '''Tools→Text''' menu item, or T on keyboard. Activate the text tool, and click somewhere on the image (to unclutter the view, make the <tt>Background</tt> and <tt>Doodle</tt> layers invisible). Click somewhere on the image, and a text input dialog will pop up. After typing something, we may obtain:

<center>http://svn.gna.org/viewcvs/*checkout*/wesnoth/branches/resources/image-localization/tutorial/gimp-text-tool.png</center>

Almost every part of this screenshots presents some important points.

On the left, the tool options for the text tools are shown. Here you can select the basics (font, size, and color), but also some other important options. The three checkboxes affect how the font is rendered: antialiasing makes letters non-jagged against the transparent background, and the two hinting options improve the shape of letters. You will almost always want to have all these checked. The justification buttons allow you to left-align, center, etc. the text. The three spinboxes bellow are used to tweak the spacing between letters (you can shrink the text that looks to wide, or shrink the distance between two lines of text).

In the center you can see the rendered text in top left corner of the image, and superimposed text input dialog over the image window. There you can also load some text from file, in case of longer texts.

On the right, in layer view, notice that the entered text got its own layer (named by the text itself), similar to what happens when selection is pasted. Unlike the temporary pasted layer, the text layer is permanent, but also special in that double-clicking its icon will allow you to edit the text at a later point (that's why its icon is a generic text-like icon, instead of showing layer content). Text layers can be changed into an ordinary layers by executing '''Layer→Discard Text Information''', but you will want to do this only if you need to do some arbitrary transformations on the text. The boundary of text layer is only as wide and high as the text, so you can move the text layer around.

=== Saving Images ===

Always save images first and formost in Gimp's native format, XCF. This will keep all the information, such as layers and selections, so that you can pick up editing the image just where you left. Consider the XCF format as your "source", on which you work and from which you "build" the final ordinary (or "flat") bitmap images.

When the image is ready for delivery, when you have made all necessary layers visible and helper or test layers invisible, you can save the image in one of flat bitmap formats. Two typical are PNG and JPEG, with the following very important difference between them. PNG is a "lossless" format, which means that every pixel in shown to the user just as it was in the source, XCF image, when the PNG was saved. JPEG is a "lossy" format, which compresses the image such that it's rather near to original, but not exactly and possibly with some ungainly visual artifacts, at the benefit of frequently considerably reducing the image size. PNG is what you will need for allmost all in-game localized images, as the originals are PNG images too. This is natural for game graphics, since it needs to be crisp, without any compression artifacts. JPEG is typically used for photographs, which would be huge if left uncompressed, and instructive screenshots which do not need crisp looks (e.g. for images in the manual).

To make a PNG image, you may as a matter of habit reach for '''File→Save As...''', and there select PNG as output format and save; then, to get back to the XCF source, you will close the PNG, and open the XCF again. To avoid this usual routine, there is the '''File→Save a Copy...''' action, which unlike '''Save As...''' will not switch to the newly saved PNG image, but let you continue working on the original XCF after saving.

[[Category:Translations]]

EasyCoding

2010-04-27T19:51:02Z

SkeletonCrew: /* GUI2 related features */ removed the tasks will think for new ones later

== Foreword ==
This page is here to document easy to do coding tasks. It is not here to double the feature request database, and should only be filled by people that know the code well enough to judge the difficulty of a given task.

If you are such a person, you should feel free to edit this page.

If you're not, you should post a feature request and discuss your idea on the forum or IRC. A coder with better knowledge of the code might give you the green light to add your feature here.

Anybody should feel free to add "clues" to any tasks, that is entry points, traps to avoid, person to contact to discuss and so on.

If you plan to work on a feature, write your name at the bottom of the feature, with the date. Note that if you are too long at working on a feature I'll "free" it back (that is if you're not working on it. If you have problems implementing it, just tell us....)

--[[User:Boucman|Boucman]] 20:48, 3 October 2006 (CEST)

Since bugs are sometimes a good opportunity to get a first idea of the code, i will add some here that are easy to fix as soon as i stumble upon them (the one i had in mind is fixed already ;-).

--Yogi Bear, 28 February 2008

== MP related features ==

=== Use different font for in-game chat ===
Since commas and dots are apparently hard to tell apart. As per FR #7470 [https://gna.org/bugs/?7470]

== WML related features ==

=== WML configurable village income / upkeep ===
Preferably as a [scenario], [side] or [campaign] keys. As per FR #6301 [https://gna.org/bugs/?6301]. Patch submitted: [https://gna.org/patch/index.php?1162] (gabba)

--[[User:Boucman|Boucman]] 08:56, 28 February 2010 (UTC) : this is postponed for 1.8, can be considered reserved

=== Add support of [if] for [scenario] ===
As per FR #4539 [https://gna.org/bugs/?4539]

=== Make [have_unit] optionaly use full SUF ===
[have_unit] by default uses SUF but does not apply it to recall list. Introduce an optional key that will allow to lift that limitation.

=== Side-specific results ===
Giving result=defeat or result=victory for specific sides. ([http://gna.org/bugs/index.php?4960 FR #4960]) -- [[User:dlr365|dlr365]] -- patch submitted [https://gna.org/bugs/index.php?4960]

--[[User:Boucman|Boucman]] 08:58, 28 February 2010 (UTC) Patch seems abandonned, but can be used for further work feel free to take over the FR

=== Support for leaderless multiplayergames ===
Add support for the WML key victory_when_enemies_defeated= in the scenario tag during multiplayergames. ([https://gna.org/bugs/index.php?8106 FR #8106])
--[[User:Endercoaster|endercoaster]] 30, March 2010. I'm gonna give this one a try.

=== Support for standalone multiplayer scenarios ===
There used to be support for standalone scenarios in the userdata tree, in reorganising the trees this feature got lost and an add-on is now required to add a scenario.
Re-add this feature. It is probably a good idea to mirror the mainline multiplayer tree.

=== Other Ideas ===
See [[FutureWML]]; some ideas there are easier than others.

== Improvements to AI ==

Fix some todos, add new formula functions, or do minor improvements to the formula language. Make it easier to debug the formula language, add more ai components.

Please discuss these with Crab, Dragonking, Sirp or Boucman

=== AI Batch testing ===

Finish patch #1169 [https://gna.org/patch/?1169]

=== Add more ai actions ===

Add an ai action (and add formula_ai function to do that) to set a goto on a unit

Add an ai action (and add formula_ai function to do that) to send a chat message to a player

Add an ai action to set formula ai variable (convert existing code from formula_ai)

Add an ai action to set formula ai unit variable (convert existing code from formula_ai)

Add an ai action (and add formula_ai function to do that) to fire a WML event

=== write a (fai or c++ or lua) candidate action for leader control ===

=== write a (fai or c++ or lua) candidate action for using leadership/illuminate ===
special handling of units with leadership to have them support units. Only do it if it actually is useful (less hits needed to kill the unit) and ability to help multiple units in a single turn (assuming enough MP)

=== write a (fai or c++ or lua) candidate action for healer control ===
Handle units with healing power, moving them at places where they can provide the most healing

=== berserker improvement ===
The default AI's strategy of attacking as much as possible is very bad with berserker... A simple AI that would prevent the berserker from attacking (and keeping him close to fight without being exposed) and attack when the chance to kill is high enough would be an interesting addition

=== power projection improvement ===
AI sometimes wants to calculate 'how much firepower can enemy bring on location X'. in doing so, it considers enemy possible moves, time of day, attacks, enemy defense, etc.
There is specific problem with 'time_of_day' used in that calculation -sometimes, it's really needed to check 'time of day for NEXT turn', not time of day for THIS turn.(since the time of day might change next turn).

power_projection must be fixed to account for the possibility of time_of_day being different.

Note that some enemies might go after us (so, still on THIS turn), and some - before us (so, their next turn will be on NEXT turn).

== GUI related features ==
-------------------

Note at the moment Mordante is working on a new GUI system, these
changes will probably affect the way these items need to be implemented.
Contact Mordante on IRC before starting to work on these.

--[[User:SkeletonCrew|SkeletonCrew]] 14:04, 9 March 2008 (EDT)

=== Theme Changes ===

* allow custom themes to display values of WML variables ([http://gna.org/bugs/index.php?6209 FR #6209])
* hide the hourglass item from the statusbar when there is no timer

=== Widget Changes ===
* show side number, name and team association information in the status table
* make games sortable in the lobby (open slots, total number of players, era, XP modifier, gold per village, fog/shroud)
* input history (chat, commands, ..) - note: rujasu is working on this feature

== GUI2 related features ==
GUI2 is the new gui engine Mordante/SkeletonCrew is working on.
* Information on the wiki can be found here http://www.wesnoth.org/wiki/GUIToolkit
* The source code is under src/gui/
* The configuration config files are under data/gui/default

Some tasks need the --new-widgets since the code is only shown in the experimental mode. Tasks which need this switch have the * in the title.

At the moment there are no easy tasks available.

== Miscellaneous ==

=== More powerful village naming ===
'''Adding mountain names and other features to village names, having a second random name in village names'''

Currently the village naming engine has a very good structure that could allow
more powerfull names to be generated.
Understanding how it works should be quite easy, and a few usefull improvements could be added.

* Currently villages can use lake names and river names, this should be extended to other features like bridges, swamps, mountains etc...
* It would be nice to have a separate list of "first sylabus" and "last sylabus" for naming. That's not really needed in english, but some translations could use it
* Again, it is common to have villages with more than one "random" word in them. having a $name2 variable would be nice

Euschn 24/03/2009

=== Debug Mode ===
* New debug command functionality (setting additional status.variables, possibly terrain)
=== Fixed parameter in a nimation ===
since we're a little short in easy codings,
[https://gna.org/bugs/index.php?13171 this feature request] is easy.

Ask Boucman for details

== Bugs ==

== See Also ==

[[NotSoEasyCoding]]

[[Category:Development]]
[[Category:Future]]

SoC Information for Google

2010-03-11T21:02:05Z

SkeletonCrew: /* Does your organization have an application template you would like to see students use? If so, please provide it now. */ Added Lua

{{Template:SoC2010}}

== SoC Information for Google ==
==== Describe your organization. ====
The Battle for Wesnoth, or simply Wesnoth, is a free turn based strategy game with role playing elements designed in June 2003 by David White (Sirp).

The game's general philosophy[1] (both for gameplay and coding) emphases simplicity. The core rules are meant to be easily learned but also provide interesting gameplay and diverse strategies. Strength of the project is reflected in application of Wesnoth Markup Language (WML), which provides a simple language to easily customize scenarios. It has created a significant modding community that has generated a considerable amount of user content.

The first stable release (1.0) was on October 2 2005, the latest stable release (1.8) anticipated in the next few weeks. According to Ohloh, a site that collects activity statistics on open-source projects, the Wesnoth development effort is in the top 2% of largest and most active projects.

We consider 1.8 to be one of the most stable wesnoth release so far. We plan our next developement cycle (1.9, leading to 1.10) to be much more disruptive with gameplay changes and new concepts to try.

This year is probably one of the best year for a SoC student to join, since this openness means much more space to develop novel ideas

Wesnoth has grown substantially and is considered one of the largest open source games around.
* two servers (stable and development) with a usual minimum load of more than a hundred players
* more than two thousands downloads a day
* 3 million downloads via sourceforge.net, many more via various mirrors of Linux Distributions
* best rated game at the linux game tome[2]
* game of the year 2007, 2008 and 2009 at linuxquestions.org[3]

Wesnoth's most notable features include;
* A mature project, but with active development and many improvements
* High quality artwork: both graphics and music
* Very well-balanced by a tireless team of playtesters
* Fun, unique gameplay
* Even after six years of development, and a very solid, fun product has been created, there are still plenty of new developers, and the number of commits to SVN is still increasing
* Strong support of internationalization with many supported languages and thus experience in working with non-native English speakers (more than half of our developers are not native English speakers)

[1] http://www.wesnoth.org/wiki/WesnothPhilosophy

[2] http://www.happypenguin.org/list?sort=avg_rating

[3] http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/

==== Why is your organization applying to participate in GSoC 2010? What do you hope to gain by participating?====
Most of our developers have particular areas of interest in which they work. Though they are efficient in their areas, there are other, presently uncovered, areas of the code with a need for improvements but a high barrier to entry for casual contributors.

Our previous SoC experience shows that a motivated, full-time, student can be brought up to date in any area fairly quickly.

By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart some areas of the project that are currently lagging behind.

Moreover, our previous experiences has shown us that SoC developers tend to stay after the end of the summer of code and are usually valuable members of our community. We would like to take the chance to add valuable members to our community.

==== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. ====
===== 2008 =====
2008 results:
Wesnoth participated in GSoC 2008 with four students. Out of these, two were great success (that is they became full-fledge developers before the actual start of GSoC), did huge improvement during GSoC (A new recruitment algorithm for the AI and the basic structure for a new map editor, the student finished this work after the summer), and are still active developers in the Wesnoth community.

Of the two other, one of them was very active for the first half of GSoC and provided some useful infrastructure for AI development that we used as base in GSoC 2009, but was much less active and didn't reach expectations for the second half of GSoC. The lesson we learned is that great students should be left on their own, that's the best way to have them work, but average students should be monitored much more closely than we did. If things seems to start to go wrong, it's important to react very quick, to meet with other mentors and get things back on track early.

Timezone problems were also a serious barrier for student/mentor communication, and we will take that more seriously into account when pairing mentors and students

For our other students, multiple problems collectively led to failure
* We should enforce IRC communication, E-mail is a barrier. This applies both for students and mentors. Both should be on IRC several hours a day, with a huge overlapping of the hours.
* We should be more strict about mid-term evaluation. If the student is slightly lacking at mid-term we should get the message clear that he needs to get back on track.

===== 2009 =====
In 2009 we mentored 6 students as part of Summer of Code. Out of these 5 projects were a success. From those 5 developers 3 are still part of our core development group and still maintain and improve the work they submitted as part of Summer of Code. One of the students even became the "head" of our AI development department and wants to mentor a student this year. For a summary of the 2009 results have a look at [1].

Sadly one student was not able to continue his work past midterm due to his computer failing completely as well as personal problems that I won't explain further in here. This is basically an issue that noone can do anything about so sadly we were not in a situation where we could somehow have made this student succeed.

[1] http://forums.wesnoth.org/viewtopic.php?f=5&t=26955

==== If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006.====
2008: 2/4
2009: 5/6

==== If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?====

We applied and participated in GSoC 2008 and 2009.

==== Who will your organization administrator be? Please include Google Account information.====
Nils Kneuper (Ivanovic)

crazy.ivanovic |ATTT| googlemail.com

==== What license(s) does your project use?====
GPLv2 (dropdown box!)

==== What is the URL for your ideas page?====
Our main summer of code page is located at http://www.wesnoth.org/wiki/SummerOfCodeIdeas

This page contains various coding ideas and the thought the development team has already given them.

It also contains a list of the developers that are the most active on IRC and their domains of interest.

==== What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2010. If your organization uses more than one list, please make sure to include a description of the list so students know which to use.====
The main development mailling list is "wesnoth-dev@gna.org". Our main means of communications is our IRC channel on freenode. If you have questions you should ask them in #wesnoth-dev on irc.freenode.net and wait for a reply (might take some hours!). The Wesnoth related channels are logged in public and the logs tend to be read by developers.

==== What is the main IRC channel for your organization?====

#wesnoth-dev on irc.freenode.net

If you have questions you should ask them in #wesnoth-dev on irc.freenode.net and wait for a reply (might take some hours!). The Wesnoth related channels are logged in public and the logs tend to be read by developers.

==== Does your organization have an application template you would like to see students use? If so, please provide it now.====
We plan mainly to meet potential students through our IRC channel, but the following questions are Wesnoth specific and are worth pondering for any student, even if we don't need a formal answer.

1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

1.4) Why do you want to participate in summer of code?

1.5) What are you studying, subject, level and school?

1.6) What country are you from, at what time are you most likely to be able to join IRC?

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

2) Experience

2.1) What programs/software have you worked on before?

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or gameplay?

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

3.2) What spoken languages are you fluent in?

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

3.6) Are you good at sorting useful criticisms from useless ones?

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

4.2) If you have invented your own project, please describe the project and the scope.

4.3) Why did you choose this project?

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

4.5) Include as much technical detail about your implementation as you can

4.6) What do you expect to gain from this project?

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?
* Subversion (used for all commits)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* Python (optional, mainly used for tools)
* build environments (eg cmake/autotools/scons)
* WML (the wesnoth specific scenario language)
* Lua (used in combination with WML to create scenarios)

5.2) Which tools do you normally use for development? Why do you use them?

5.3) What programming languages are you fluent in?

5.5) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

In general please try to be as verbose as possible in your answers and feel free to elaborate.

==== Who will be your backup organization administrator? Please include Google Account information.====

==== Who will your mentors be? Please include Google Account information.====

Jeremy Rosen alias Boucman (boucman2|ATTT|gmail.com)

Yurii Chernyi alias Crab (terraninfo|ATTT|terraninfo.net)

Mark de Wever aka Mordante (mordante.wesnoth|ATTT|gmail.com)

==== What criteria did you use to select these individuals as mentors? Please be as specific as possible.====
Our first criterion was that all the people had to be volunteers. According to other open source projects and our experience from the last two years, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.

Boucman is one of the oldest active developers around. He has rewritten the whole animation engine and made it an easily pluggable system allowing artists to easily specify exactly how they want the units to appear. He also started many community oriented projects like the Art Contribution[1] section of the wiki (now deprecated) and the WML Reference Manual[2]. He is responsible for dispatching and sorting the patches at http://patches.wesnoth.org that has created the new developer process we currently use. Boucman was a mentor in 2008 and 2009.

Yurii Chernyi (Crab) has joined the team in 2009, taking part in Google Summer of Code 2009, and staying with the project as a developer after successful completion of GSoC. He's an expert on all aspects of current Wesnoth AI codebase (having fully reorganized it as part of GSoC 2009), and has fixed numerous bugs all over Wesnoth. He is experienced in teaching other people, in areas like programming languages and math.

Mordante is one of the most active developers on our IRC channel. Not only has he done preliminary studies and coding in multiple areas that are candidates for Summer of Code ideas, he also is one of the coders with the best overview of the Wesnoth code. A large part of his work involves refactoring and polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base. He is currently completing a rewrite of the Wesnoth GUI library, making all windows configurable through WML. This should make it easier to use Wesnoth on different resolutions, from small handheld devices to large 30 inch screens. Mordante was a mentor in 2008 and 2009.

All other developers listed in the ideas page are the leading capacities we do have for the respecting areas. Have a look at our list of "people who to contact" [3] for an easy reference. In general all our developers will mentor all students. That is, questions should just be asked in our IRC channel, where basically every developer who has an idea can and will directly answer.

When choosing the mentors, we have kept in mind that most developers can answer most technical questions, and we have chosen people that are well known for interacting with new-comers/external developers and can provide general guidance and design advice, more than people with specific technical knowledge.

[1] http://wiki.wesnoth.org/UnsortedContrib

[2] http://wiki.wesnoth.org/ReferenceWML

[3] http://wiki.wesnoth.org/SoC_People_to_bug_on_IRC

==== What is your plan for dealing with disappearing students?====
The first thing to do is to avoid this situation altogether.

Wesnoth is a game, and as such has lots of developers that are not coders. In particular, artists are well known in the Wesnoth community for being very sensitive about criticism and our community is used to people being sensitive to critics.

We will try to choose students that accept criticism and are able to filter constructive criticism from useless one. The Wesnoth developer community is used to judging people according to these criteria and the special title we are going to give to applicants will allow us to easily spot any such problems and discuss them before they grow out of control.

If a student disappears, their mentor will be in charge of recontacting the student to see what is going wrong (available time, tension with other developers, with members of the community etc...). Depending on the actual problem, the mentor and the student will have to agree on possible ways to defuse the problem.

If a student disappears completely and there is no way to get back to them, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have SVN write access, so most of the work will be committed either to trunk or to a specific branch) and find a core developer to take on the job. This will probably be slower and less effective for the project, but it's the best we can do.

==== What is your plan for dealing with disappearing mentors?====
All our mentors are long time developers that volunteered for the job, so we don't expect that to happen. We observed in 2008 the amount of time required to mentor, and our mentors accepted the job knowing the amount of work it involved. Most of them were mentors last year too.

However, should it happen, we would continue to mentor as a developer community the student until we find a new "official" mentor to take on the job.

==== What steps will you take to encourage students to interact with your project's community before, during and after the program?====
Wesnoth has a particularly healthy community, both for developers and for players.

Our general policy regarding new coders has always been "two (non trival) patches... you're in". With other words, anybody that is able to get two non-trivial patches applied is offered commit privileges.
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our EasyCoding pages [1] (these projects are usually a couple of hours long and hve been chosen to provide easy access to the respective area of code).

Usually, patches go back and forth a couple of times, to make sure that all secondary things are in place (indenting, coding style, modified buildfiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to keep our project alive.

If the student is proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.

In 2008 and 2009 all students that were accepted (and a couple more) managed to have commit access before the start of the coding phase. We consider that this policy was successful and we plan to keep it this year.

We also plan to give a special forum title to any students. This will allow all forum members to tell them apart from normal users and give them read/write access to the developer only forums. This will also allow us to quickly spot any problem they might have interacting with the player community. We have a very mature developer community, but our player community is made of all sort of people of all age and education, and it can sometimes be rough.

[1] http://wiki.wesnoth.org/EasyCoding

==== What will you do to ensure that your accepted students stick with the project after GSoC concludes?====
Since our community has a history of having developers join easily and quickly, we expect the student to be a full-fledged developer quite fast (probably a little after the end of the bonding period).

Thus there will be no "end of GSoC" transition. At the end of the Summer of code we expect the student to be responsible for the part he developed, and to continue taking care of it, just as other developers are responsible for their part. In general we show students that we appreciate their work by directly having most of the work happen directly in trunk. So their work is included in each development release right from the start. No need for any merging of external branches or the likes. Their work is handled like the work of any other developer we have.

In 2008 both students that succeeded stayed and are still active developers. Three of the students from 2009 are still active developers, one even applying to be mentor this year.

==== Is there anything else you would like to tell the Google Summer of Code program administration team? :====
There is nothing more to say.

SoC Ideas Gui2 Input

2010-03-07T09:59:52Z

SkeletonCrew: minor formatting fix

{{Template:SoC2010Idea}}
=Description=
<h3>Port Wesnoth input framework to a more flexible system</h3>
Since 2007, Wesnoth has been rewriting its GUI system with a more flexible system
allowing all user interface aspect to be specified through WML. One of the
changes has been to change the GUI input system. The input system still only
support keyboard and mouse. With the rise of the more powerful hand-held
devices(hand-held game consoles and phones) Wesnoth gets ported to these
devices as well. The scope of this SoC project is to add more different kind
of input devices like pads and touch screens.

= Additional Information =
The project is divided in several sub projects:
* Add the new input devices to the gui2 framework.
* Make it possible to select and configure the input devices.
* Port the gui1 interfaces to use the new input sub system.

In the sections below the steps are discussed in more detail.

== Add devices to gui2 ==
The SDL project is currently working on version 1.3 of their library, which
has several improvements for the iPhone. SDL hasn't been released yet and
there's no firm release date yet. It would be interesting to see whether the
input system can use SDL-1.2 and SDL-1.3 with some ifdefs.

== Configure input devices ==
Since the number of buttons and placements of the button differ per device
the user should be able to configure which buttons to use and assign
functions to them. A dialog should be added for this. Preferably the dialog
also shows which button is pressed at a certain moment so the user can see
how Wesnoth calls the button on that device.

== Port gui1 to new sub system ==
Once the gui2 part can use the new input system it also needs to be ported
to the old input system. (Porting the old gui is long process, porting the
input system will be faster and easier.)

SoC Ideas Gui2 Input

2010-03-07T09:58:06Z

SkeletonCrew: rewrote the proposal

{{Template:SoC2010Idea}}
=Description=
<h3>Port Wesnoth input framework to a more flexible system</h3> Since 2007,
Wesnoth has been rewriting its GUI system with a more flexible system
allowing all user interface aspect to be specified through WML. One of the
changes has been to change the GUI input system. The input system still only
support keyboard and mouse. With the rise of the more powerful hand-held
devices(hand-held game consoles and phones) Wesnoth gets ported to these
devices as well. The scope of this SoC project is to add more different kind
of input devices like pads and touch screens.

= Additional Information =
The project is divided in several sub projects:
* Add the new input devices to the gui2 framework.
* Make it possible to select and configure the input devices.
* Port the gui1 interfaces to use the new input sub system.

In the sections below the steps are discussed in more detail.

== Add devices to gui2 ==
The SDL project is currently working on version 1.3 of their library, which
has several improvements for the iPhone. SDL hasn't been released yet and
there's no firm release date yet. It would be interesting to see whether the
input system can use SDL-1.2 and SDL-1.3 with some ifdefs.

== Configure input devices ==
Since the number of buttons and placements of the button differ per device
the user should be able to configure which buttons to use and assign
functions to them. A dialog should be added for this. Preferably the dialog
also shows which button is pressed at a certain moment so the user can see
how Wesnoth calls the button on that device.

== Port gui1 to new sub system ==
Once the gui2 part can use the new input system it also needs to be ported
to the old input system. (Porting the old gui is long process, porting the
input system will be faster and easier.)

SoC People to bug on IRC

2010-03-07T09:11:13Z

SkeletonCrew: /* Mordante */ add boost asio line

{{SoC2010}}

== People to bug on IRC ==
We have prepared a list of people with their "area of competence". This is to give you an idea on which areas those people can be of help for you. Of course you should always just ask in the IRC chan, but those are the most likely ones to answer questions in the respective area. And here is the list:

=== boucman ===
As our "patch monkey" he accustomed to critiquing patches of every kind. Beside this, he knows many areas of the game due to working on applying patches. He is particularly used to answering question from new coders, and doesn't mind explaining trivial stuff. He was the one who started the "two patches, you're in" policy and the ReferenceWML part of the project.

=== Crab ===
Yurii Chernyi (Crab) has joined the team in 2009. He restructured Wesnoth AI as part of GSoC-2009, and is an expert on all aspects of current Wesnoth AI codebase. So, he's the person to ask about anything in '''src/ai'''. He also knows much about campaign units/leaders persistence. He also knows how to compile on Windows using MSVC 2008 and has the archive with all the required dependencies for that.

=== Dave alias Sirp ===
Sirp started Wesnoth and is our lead developer. He is currently our C++ expert and is also the one that is working on the new Formula AI. Any questions regarding the formula AI should be directed to him.

=== Dragonking ===

He is one of our best Wesnoth players, and understands the various strategies well. He has also programmed much of the Wesnoth Formula AI system and understands it well.

=== Elias Pscherning (elias) ===
He wrote the original version of campgen and as such will know a lot about what is needed to to make such an editor work correctly. The work on a scenario editor might be based upon campgen and as such his knowledge will be really helpful.

=== Eric S. Raymond (ESR) ===
ESR is our project toolsmith; he has written several tools that semi-automate various aspects of WML maintenance. While most of our developers/designers concentrate on either the C++ core or WML but not both, he has a balanced understanding of both levels and may be helpful in helping students develop a grasp of the overall architecture. Finally, he did the last overhaul of the Wesnoth UI and understands UI design principles; he is well-equipped to guide students working in that area.

=== Happygrue/Wintermute ===

A recent addition to the development team, Winter has recently been helping to test the AI and is a useful person to ask about behavioral problems in this area.

=== ilor ===
2008 GSoC student, worked on and maintains the new map editor in Wesnoth 1.5/1.6/1.7. Has some fairly recent experience with getting "in" the Wesnoth codebase.

=== Karol Nowak (grzywacz) ===
Two years he participated at GSoC as a student, so he will understand the situation of GSoC students. Beside this he is our top expert on Wesnoth for embedded devices as he worked on the gp2x support.

=== loonycyborg ===
Maintainer of Wesnoth's SCons build system and windows packager. Might also help out with other buildsystems.

=== Mordante ===
Many of the possible projects involve the code for which he is an area expert. Also, many of the possible projects currently listed on the ideas page require GUI parts to work. Mordante is currently busy rewriting the old gui engine, he will be our expert there as well as already being our area expert for the terrain engine. He also has limited experience with boost asio.

=== Nils Kneuper (Ivanovic) ===
He is doing nothing special, he just does some "administrative work" like packaging fresh tarballs when it is time for them and works on setting up any kind of deadlines and timetables related to releasing. He has administrative powers in most areas, no matter if website, forum or IRC. Beside this he uploads translation updates, tries to communicate with the translation teams when it is required and translates a little bit himself every now and then. But in general he is not a real expert in anything, just has a look at things that come up and redirects people to the correct contacts.

=== Noy ===
Noy is an oddity among developers; he's got no coding skills whatsoever and possesses a limited understanding of computers, which is illustrated by his difficulty operating a Mac. Instead, Noy makes his contribution in gameplay and multiplayer design, drawing upon his background in social sciences research, military strategy and playing games online, to understand the effects of development on the playing community behavior. Along with Soliton, Noy is a useful conduit to discuss any issues in this area.

=== Noyga ===
Another versatile developer, on the C++ side he doesn't concentrate on a particular area, did some tweaks to improve translations in some languages (like enabling the female forms for names in various place) but know quite well the C++ side of units, abilities and WML. On the WML side he's an expert.

=== Sapient ===
This developer started working on the GUI and widgets, but recently he focused more on improving the internal mechanics of the WML engine such as variable look-ups and filtering. Sapient is not as active anymore but he does come one IRC in the evenings (U.S.A.). He has touched-up many areas of the code in small ways over time, thus he has a good general knowledge of the C++ code and also has worked a little on some python maintenance scripts.

=== Shadow Master/ShikadiLord ===
He has been around since late 2007, and has worked in many areas of the engine, including the game events handler, the image path functors and the add-on management engine. As an add-on developer, he knows a lot about the WML language itself (preprocessor, basic structure) and its various single-player oriented dialects. He may also answer different kinds of questions about C++ as long as you don't start cursing the language.

=== Soliton ===
He knows our MP server setup best. Beside this he has already done a lot of work on the MP server himself. So he probably has most knowledge about it and, being one of our MP-developers, might provide important help from the perspective of the MP player community and what is needed there.

=== YogiHH ===
Since he is the developer who know most about building under Windows, he will probably be really helpful. Either if the student comes from the Windows side, or to help test resulting work to make sure that it does work on Windows and, for the case that it does not, to show them where problems are.
YogiHH also knows quite a bit about the game engine and everything that has to do with replays and savegames.

=== zookeeper or Mythological or Rhuvaen ===
As our leading WML experts those are to be contacted when it comes to anything related WML problems since they know this stuff best. They do maintain most of the campaigns and improve them whenever they have a good idea for changes.

SoC Ideas Addon Server

2010-03-07T09:04:02Z

SkeletonCrew: Remove from the gsoc ideas since ilor does this for an uni project

=Description=
<h3>'''Improve Wesnoth Addon Server'''</h3>
Wesnoth has an addon server which offers users to upload user
made content (UMC). This allows all other users of Wesnoth
to easily download and install this content. The server was
originally written for user-made campaigns but contains a lot
more types of addons nowadays. Both the server side and the
client side need to be improved.

=Additional Information=
==== General description ====
Neither the server nor the client side of the addon server have
seen much improvement over the years; both are overdue for a reworking.
The client side GUI needs polishing. For the
server side we would like to allow better integration with
various tools (such as wmllint), which improve the quality of the addons.

===== Server side =====
The server code either needs to be updated or rewritten, the student is free to make this decision him or herself. The student may choose the language for the server, but because some of the code that needs to be integrated is Python we'll need to hear a specific justification for any other choice.

* The server only needs to run on Linux systems. Cross-platform portability would be nice but isn't required.
* At the moment there's a rudimentary integration with our translation project Wescamp. This needs to be improved. Upon uploading the new content needs to be send to Wescamp (via a svn commit). And the translations need to be fetched on a regular basis.
* We have various tools to check the WML code and also upgrade it to newer version. The addon server needs to be able to run those tools on the content.

===== Client side =====
The client side needs improvements. There are two main clients;
one built in to the C++ game binary, and a standalone inmplementation in Python.

* Upgrade the GUI. Mordante is working on a new GUI library which is intended to make it possible to make the wanted changes.
* Make it easier to see summary and status information on addons. At the moment a lot of new users download something and have no clue what kind of addon it is.
* Make it easier to see whether a newer version of the addon is on the server and update the addon.
* Make it easy to select which translations you want to download and also look for newer versions of the translations.

==== Required knowledge and talent ====
* Knowledge of C++, the game is written in C++ and modifications need to be made there.
* Knowledge of Python, various tools have been written in Python which need to be integrated with the new server.

==== Milestones and deliverables ====
* The first step is to determine what exactly needs to be done and determine in which language the server will be rewritten. This includes, but isn't limited to:
** Determine the exact feature set.
** Protocol changes needed.
** Methods to integrate with both the WML tools and Wescamp with the new server.
** Determine the GUI for the client side.
** Justify the choice of language.
* These points will need to be presented and discussed with the mentor(s).
* The next thing in to implement the feature set. The code needs to be fully functional and committed in trunk.

GUIToolkit

2010-01-03T16:57:55Z

SkeletonCrew: /* Todo list */ minor status update.

= Introduction =

This is a new toolkit aiming to make it possible to make the look of Wesnoth fully skinable.
This will be used in Wesnoth the make it easier to optimize for different screen resolutions.
The initial work in progress version has been released with Wesnoth 1.6. Since the development
isn't done yet, these pages reflect the state of the trunk.

The engine has two parts:
* Widget definition, which defines how a widget looks.
* Window defintion, which defines how a certain window looks and it uses the widget definitions.

= Todo list =
Here's a(n incomplete) list of items which still need to be done.
* The layout engine can still have problems with not finding a solution and stop.
** Make sure labels buttons etc can shrink and show ellipses to shrink small enough
** Optimize the shrink algorithm
* The code for the events is not entirely to my liking and I want to look at using signals instead, events are there bug not yet used everywhere.
* [[EasyCoding#GUI2_related_features]]
* Improve the markup for the text
* Convert more dialogs

= Links =
* [[GUIVariable]] describes the variable used for the parts of WML.
* [[GUILayout]] describes how to place widgets in a window.
* [[GUIWidgetDefinitionWML]] describes how the various widgets are defined.
* [[GUIWidgetInstanceWML]] describes the options which can be used when a widget is "instanciated" in a window definition.
* [[GUIWindowDefinitionWML]] describes the windows available and which widgets the 'know' about.
* [[GUIToolkitWML]] describes the basics of the engine.
* [[GUICanvasWML]] describes what to draw on a widget.
* [[Wiki_grabber]] describes the tool to generate the wiki pages.

= See also =
* [[GUICanvasWML]]

[[Category:WML Reference]]
[[Category: GUI WML Reference]]

Fosdem2010

2009-12-05T16:10:46Z

SkeletonCrew: /* Schedule/Plans */ add myself to the fosdem list

== General information ==
This page is meant to somehow coordinate the small Wesconf taking place at FOSDEM 2010. That is everyone attending should please list him/herself in the list of arrivals and stuff like this. FOSDEM 2010 will take place at the first weekend in Febuary 2010, on Saturday 6th and Sunday 7th.

* Fosdem - http://fosdem.org/2010/
* [http://www.wesnoth.org/forum/viewtopic.php?p=283311#283311 List with phone numbers] (forum moderators only)

== Schedule/Plans ==
{| border="1" width="100%"
|-
! (nick)name(s)
! Arrival
! Departure
! Accomodation
|-
| Ivanovic
| Fri, 5th
| Sun, 7th
| unknown
|-
| Crab
| Fri, 5th
| 7th or 8th
| unknown
|-
| grzywacz
| Fri, 5th (?)
| Mon, 8th (?)
| unknown
|-
| Boucman
| Fri, 5th (?)
| Mon, 8th (?)
| unknown
|-
| mordante
| Fri, 5th
| Sun, 7th
| unknown
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|
|
|
|
|-
|}

For accomodations please keep in mind that parking in the center of Brussels is really problematic. It might make sense to drive to the University where FOSDEM takes place, park there and take the bus into the town center (where some of the hotels/hostels are).

Possible hostels that we at least contacted over the last years (some of them might already be booked out by now!):
* [http://www.chab.be/ CHAB]
* [http://www.2go4.be/ 2go4] Note: groups bigger 6 are not allowed, so we can (officially) not form a complete Wesnoth group at this hostel, got to meet somewhere in town/at the university...
* [http://www.jeugdherbergen.be/brusselE.htm Bruegel YH]

On the official FOSDEM page [http://fosdem.org/2010/practical/accomodation some more possible hotels/hostels] are listed.

== Maps ==
* [http://tinyurl.com/3a65gr Bruegel YH]
* [http://tinyurl.com/35br9c Brussels Central (Train Station) → Bruegel YH]
* [http://tinyurl.com/37d9v4 Bruegel YH → Brussels Central (Train Station) → Novotel Grand Place]
* [http://tinyurl.com/2mzns6 Novotel Grand Place]
* [http://tinyurl.com/3dggg3 CrownePlaza (Europa)]
* [http://tinyurl.com/36epxj FOSDEM]
* [http://tinyurl.com/2w4bms Novotel Grand Place -> FOSDEM]

== Transportation ==
Information about how to reach the FOSDEM is listed at the [http://fosdem.org/2010/practical/transportation official transportation subpage].

Short version of how to get there for those that reside in Bruegel YH and Novotel Grand Place (basically town center):

* Enter Bus 71 (Debrouckere - Central Station ("Gare Centrale") - Delta) somewhere at 'Central Station'
* Leave the bus at "ULB" (crossroads Ave. Adolphe Buyl - Sq. Deveze)
* Walk down Ave. Paul Heger on your right hand.

== Wesnoth Hacking Room ==

Wesnoth will not have a room of its own. Instead we will use one of the "general hacking rooms". So far it is not sure which room it will be, if we do it like the last two years, it will be room number 115 in the building AW1. Last year this was the smaller of the two hacking rooms and we had no real problem with conquering (and holding) the first row in this room. There were not too many power outlets, so this year at least Ivanovic will bring one multi-outlet power strip plus some extension cable (5m or something like this). There is no wired network, everything wireless (and sometimes rather/very unstable!). Beside this you should bring laptops since there are no computers available for hacking.

Short version:
AW1 - Room 115

== Planned discussion ==
We usually discuss all sorts of things at FOSDEM, this section is here to have a small bullet list of things that we actively want to discuss at FOSDEM.
* GSOC 2010: finding mentors, organizing the submission etc..
* FOSDEM 2011 : trying to get a dev room with other games ?
* [wanted: discussion topics!]

== FOSDEM 2009 ==
We were already at FOSDEM 2009, here something as reference:

* [http://www.wesnoth.org/wiki/Fosdem2009 FOSDEM 2009 wiki page]

== FOSDEM 2008 ==
We were already at FOSDEM 2008, here something as reference:

* [http://www.wesnoth.org/forum/viewtopic.php?p=283649#p283649 Forum topic (with group photo)]
* [http://www.wesnoth.org/wiki/Fosdem2008 2008 wiki page]
* [https://mail.gna.org/public/wesnoth-dev/2008-02/msg00078.html Summary of FOSDEM 2008 results]

[[Category:Development]]
[[Category:Wesconf]]

Wesnoth1.8Features

2009-09-05T08:48:45Z

SkeletonCrew: /* Mordante */ Update my 1.8 status

=Stuff people are working on=
== Mordante ==
=== Will complete ===
* Polish cmake into a good working state for users (done)
* Various improvements to the new gui
* Finish the new in game dialog (http://www.wesnoth.org/forum/viewtopic.php?f=18&t=25585) (in progress)
* Finish the bugs in the lobby (items marked with [M] http://www.wesnoth.org/wiki/MP_Server_Ilor#Remaining_issues)
* Rewrite the layout algorithm (in progress)

=== Wants to complete ===
* Finish the cmake pot-update
* Experiment with boost asio for a new addon server
* Rewrite the tooltips
* Add new widgets
** horizontal listbox (done)
** look at horizontal and vertical grids
* Finish the new widget system
* Open bugs assigned to me

=== Hopes to complete ===
* Open FRs assigned to me

=== Completed ===
* Improve campaign selection dialog (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497655) (Note there are some problems so it might be that this gets postponed until 1.7.)

=References=

[[TextdomainStatus|current status of textdomains]]

[http://bugs.wesnoth.org bugs.wesnoth.org] - List of known and reported bugs

[[Category:Development]]

MP Server Ilor

2009-08-16T14:07:10Z

SkeletonCrew: /* Blockers */ Updated the bug status

Note: This project was accepted into GSoC 2009.

==About me==
My name is Tomasz Śniatowski, ilor on irc/gna/forums/wiki, I'm a third year software engineering student in the Wroclaw University of Technology in Poland. My preferred e-mail adress is kailoran(at]gmail.com

I chose to participate again to allow myself to focus on Wesnoth development during the summer i.e. earn summer money while doing something fun. Wesnoth was my default choice for an organization as I feel that being already familiar with the code will allow me to be much more productive.

==Experience==
===Wesnoth===
Last year I successfully participated in Summer of Code, completing the [[Editor2]] project. I am currently maintaining the new map editor and sometimes doing some small random fixes or features around the code.

===General===
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) that automated some tedious tasks. Some time later I got involved for a while in another browser based game, a local text MMORPG under construction ([http://idarionis.com]). I wrote several helpful Greasemonkey scripts, such as a simple ajax-ification of part of the game, that I hope will be integrated into that game someday. I also had some chats with the game developer and helped him with some PHP and database stuff. I'm not more involved there because the developer wants to keep it a one man job for now, and it's a closed project which makes it appeal to me less and less.

I also have some intermediate-level database knowledge, mostly MySQL for webapps and MSSQL for a proprietary accounting application I helped deploy and maintain in a small company. Right now I'm in the middle of a database design course at my uni but I'd rather not talk about it. It's in MS Access and that should be enough.

I have also coded some websites as a kind of part-time job. This included using an established framework (Zend) and adapting and maintainng open-source software installations (oscommerce).

I have mostly worked on my own, though once or twice I coded something with 2 or 3 friends. A notable example from this school year was writing a simple raytracer from scratch (in C++), which later became the basis for a distributed systems project. This was a very interesting experience, especially since eventually it all worked fine. The raytracer I wrote on my own, the distributed bit was in cooperation with a friend. We ended up modularizing the project which allowed us to work efficiently, and the project was well-received by the profs.

==Gaming==
I played lots of various games, from strategies both real-time and turn-based to shooters and RPGs. I tend to play mostly singleplayer, and like a good story in a game, though some games, like racing sims, don't really need one. I also think that bad gameplay can kill a game regardless of story. I also really prefer solid gameplay to stunning visuals, possibly because I could never justify buying a high-end gaming rig. I have played some Wesnoth campaigns, enjoyed them, but generally find myself not having time for a lot of games lately, including Wesnoth.

==Communication skills==
English is my second language -- my first is Polish. I have no trouble communicating in English in any way. I consider myself fairly good at interacting with other players and developers. I try to give advice when I can and when I am fairly confident it will be correct. I don't really like people who keep giving "advice" despite not knowing much. I'm perfectly fine with receiving advice, I generally prefer having someone look over my ideas especially when starting on something new. Sometimes I ask for help, sometimes I make it a point to figure out stuff by myself.

==Project==
The project is to extend the wesnoth multiplayer server and the client-side lobby interface, as outlined in [[SoC_Ideas_Multiplayer_server]]. There are essentially two parts to the project, an UI ovarhaul in the client and some modifications to the server, with choices to be made in both cases.
===Design considerations===
==== Lobby channels/rooms/filters ====
Channels are probably the most common way of handling larger audiences, but there are concerns that it'd split the community, and make moderation more difficult. One other idea was a "chat filters" thing, but I'm not entirely convinced it'd work well. Regardless of the choice, I think all users should start in the general lobby by default and only move elsewhere if they really need to. Assuming channels, I'd make it so everyone's in the lobby always, but can join a different room if they want to. A tab-like interface would allow switching rooms, as is common in chat apps, irc etc.

==== Wesnoth-less wesnothd chat / moderation ====
In general starting up Wesnoth takes a while and keeping it on is a bit of a hassle. An irc-server-like interface to allow moderation would be very welcome, but I think might be too difficult. If we'd want to mirror the room structure into a server, I think the best approach would be to extend an existing modular ircd with a wesnoth interface.

Extending the lobby bot would be another option esp. if we don't do channels. The bot is in perl which I don't know well but I probably could manage if the scope of the canges required there would be small enough.
==== Ranking ====
It seems well established that ranking should not be a part of the server. If anything, a method of veryfing that a game has been played (by e.g. the server publishing replays) could be desirable to help ladder efforts, but this has been determined to be fairly low priority. Also Soliton seems to have taken matters into his own hands and worked on that. Ditto for a surrender feature (as opposed to quit), which is possibly complicated and not really in the scope of the project.

==== Server-side RNG ====
It came up that it would be useful to delegate the random number generation to wesnothd to alleviate some potential cheating (predicting next RNG rolls since the client knows the seed). It would involve the client asking the server for a bunch of random numbers to be used as a seed whenever it needs to do some dice-rolling. This can potentially bring some unwanted lag, but the added security might just make it bearable.

After some discussion it seems that a reasonable idea would be to have a new delegating RNG in the game that would have a special state variable (validity). The RNG would become invalid after every action that involves user interaction (like unit movement, attack selection, deciding to recruit, answering a WML dialog question, etc). When a random number is required and the generator is invalid, it will ask the server for a new random seed. If the RNG is valid, it'll just generate another number. This way there are no changes to be done in WML and the random numbers become safe.

The WML side of this is a bit tricky, it might be required to add another method of RNG generation to split "private" and "shared" random numbers. This will also require in-depth investigation of how the data about what's happening ingame is sent around. It is much simpler in the (far more crucial imo) case of combat -- when the final decision to attack is made (attack type is selected) the game will ask the server for a seed to be usd in this combat only, making combats unpredictable and cheat-proof. This should be enough to test the validity of the entire approach.

===Server-side details===
====Maintenance work====
The server looks like it needs some maintenance. Having the lobby be a special game works, but isn't really logical and leads to hacks and workarounds. I'd extract the common actions for games and the lobby into a superclass and derive Lobby (or Room) and Game from that class. Documenting along the way would be helpul, too.
====Options are not necessarily bad====
I think that regardless of what we decide to implement, there should be a way of disabling it (other than reverting all the changes). For instance, if we implement rooms, there should be a simple "one_lobby=yes" value to set in order to revert to a behavior similar to the old one. Even if we decide not to do a feature, I'd rather have the code written in a way that would allow adding it later without having to redesign half the server (or client).
====Server-side RNG====
The server bit of the server RNG looks rather simple. The server just needs to maintain a RNG and send random numbers to clients when asked to.

===Client details===
==== Redo the interface in gui2 ====
There's little point in trying to expand the old widgets lobby when there's a new toolkit around. Some new widgets will have to be created first, notably the minimap and a tab control. Tabs could be simulated by buttons though.
==== Concept sketch ====
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]

==== More games shown at a time ====
The current UI shows only 4 or 5 games and wastes a lot of screen space. My idea would be to collapse all games except for the selected one into much smaller bars with a smaller minimap and less information, possibly by using icons and/or skipping some redundant text. The selected game would have a similar look to what's there now, with the notable addtion of the join and observe buttons which I think would work better near the game as opposed to somewhere on top. This would also help save some vertical space which is usually at a premium.
==== Powerful game filters ====
There should be a method of filtering to search for games with a particular era, games that allow obervers or not, game names, creator names etc. I think this should be accomplished by a combination of filtering and sorting the game list. To avoid confusion, I think the game list should display "Games: showing NNN of MMM" to indicate that a filter is active.
==== More chat space ====
A button to expand the chat window so more text fits, at the expense of the game list. The userlist could also be hidden, but I'm not sure what could reasonably be done with that space as there's usually enough space horizontally.
==== Private chat tab ====
We already allow private messaging via the /whisper command, but it's not very convenient. I think a query-like separate window for private chats could be useful, similar to what irc clients do. I also think that such windows should display a reminder on how to use the ignore list and how to restrict private messages to friends only to make it easy for people to avoid abusers.
==== Player list improvements ====
The colors and fonts used to signify players in the current gamel, nick registered status etc are not immediatelly obvious to me. I'd add small textual info to separate the groups, and avatar-like status icons to indicate different types of users (unregistered, registered, moderator etc.). If we consider adding a ranking system, the "rank" could also be indicated by a different icon. I'd rather not allow custom icons. Since there will be no ranking in the project, this bit is moot.
==== Server-side RNG ====
Implementing that in the client might require some engine changes but mostly will need lots of engine *understanding*. This is quite orthogonal to the rest of the project and also it's not yet certain how much of an impact the added delay would have. Therefore I think it'd be good to implement a prototype of this early (e.g. with combat only, disregarding WML random numbers) just to see how it works in practice. Then it should be decided whether or not to proceed and whether or not this feature should be optional so players can disable it if they can't stand the lag.
===Milestones===
The idea page indicates that the first milestone should be a summary of studies and proposed interface changes, but disucssion revealed that a concrete list of features and milestones would be preferable '''now''', and this is the approach I'm taking.
====Decisions====
As for the design decisions, my take is:

* Ranking is out, as a conscious design choice that I understand and kind of agree with.

* I think that in general rooms are the way to go, but if another idea solidifies before the project begins, I can imagine adjusting the design and milestones accordingly if it is generally agreed to be better. Right now I think a flexible room system is the best option.

* In particular, I think the room system should be flexible enough to allow limiting users to a predefined set of rooms, for example consisting of the main lobby and language-based channels only. (note that *allow limiting* is not the same as just *limit*)

* regarding wesnoth-less moderation, after some thought I think that upgrading the lobby bot to accept mod commands is the most reasonable choice. It should be fairly simple to implement, unlike the irc server module idea, and just as useful unless we'd want to moderate dozens of channels which probably wouldn't work anyway.

====Feature short list====
# A gui2 lobby
## New gamelist
## New userlist
## "More chat" and "more games" modes
## Private messages tabs
# Game filters
# Configurable room system
# Server-side RNG
# Some method of wesnoth-less moderation
====Things to do before the program starts====
* preliminary wesnothd refactoring (e.g. split lobby and game classes)
* writing missing gui2 widgets (minimap, tabs)
* <del>investigate</del> bug Mordante about gui2 tooltips
* understand the current client-server protocol
====Timeline====
* May 26 (official program start) - have most of the initial stuff above done
* June 28 have the server-side rooms in a working state, a protocol update with (possibly interface-less) support in the client, plus a (non-functional) prototype of the new lobby gui
* July 5 have a prototype of the server-side RNG done, test how it works
* July 12 (midterm evaluations deadline - 1 day) - have a working "new lobby" with basic room support, simple filters, user list. Possibly without mode switching (1.3). Decide on what to do with the server-side RNG.
* July 26 - have the planned features roughly done. Start polishing and work on the wesnoth-less moderation. Have a decision on whether it's a lobby bot upgrade or something more.
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.
====Goals====
{| border="1"
! ID
! NAME
! PRIORITY
! RESULT
! PROGRESS
|-
| 0
| Missing gui2 widgets
| MANDATORY
| Write the minimap widget (unless someone beats me to it [1]) and probably test it somewhere in the editor. Also loook into a tabbed control (not really mandatory since I'll be able to make do with buttons)
| done (by others)
|-
| 1
| Initial wesnothd refactor
| MANDATORY
| Make the lobby a separate class and not a hack in the game class. Extract common functionality into a base class or a utility class. Document code along the way.
| done
|-
| 2
| Gui2 tooltips
| OPTIONAL
| Look into being able to show gui2 widgets as tooltips (i.e. not just text). Optional, since it'd be nice to have but nothing will rely heavily on it.
| skipped
|-
| 3
| Understand the MP protocol
| MANDATORY
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.
| done
|-
| -
| 0th milestone
| MILESTONE
| Would be nice, but not required, to have the above done when the program starts (May 26)
| n/a
|-
| 4
| Update to the MP protocol
| MANDATORY
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])
| done. Updates to be done if protocol is expanded.
|-
| 5
| Server-side rooms
| MANDATORY
| Implement the server part of the room system. Have a room class or equivalent, and the proper server behavior to react to "/joins", "/parts" and messages in general.
| done
|-
| 6
| Client-side rooms
| MANDATORY
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.
| done
|-
| 7
| Simple gui2 lobby
| MANDATORY
| Write a simple lobby in gui2. Doesn't have to include any of the "new" ideas for the lobby look, can be just a crude imitation of the current lobby with "a" game list, "a" playerlist and "a" chat window.
| done (very crude)
|-
| -
| 1st milestone
| MILESTONE
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.
| Delayed by a week, done.
|-
| 7.5
| Client-side rooms logic and logging
| MANDATORY
| Write the non-gui parts of lobby room logic (keeping info about the rooms the player is in, what players arein what rooms, what games are on the server etc)
| done
|-
| 8
| Proper rooms in gui2 lobby
| MANDATORY
| Write a proper tab-based (or fake tabs with buttons) interface for having many rooms open in the lobby, and interface for joining and quitting rooms.
| done
|-
| 9
| Proper game list in gui2 lobby
| MANDATORY
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.
| done (two modes idea delayed for now)
|-
| 10
| Game list filters
| MANDATORY
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list
| done
|-
| -
| 2nd milestone (midterm)
| MILESTONE
| Have the above done by July 12.
| done
|-
| 11
| Advanced game list filters
| OPTIONAL
| Write more game list filters like filtering by era, filtering by eras the player has, text-matching for stuff beyond the game name etc. plus a fancy interface for it.

note: Will need a "widget wrapping horizontal container" to be "fancy" and allow more filters in a neat way that works on many resolutions withouit wasting space
| delayed, 40%.
|-
| 12
| Tab interface for whispers
| OPTIONAL
| Write the tab interface for private messages
| done
|-
| 13
| Proper userlist in gui2 lobby
| MANDATORY
| Write a rough equivalent of the current player list with some upgrades (group labels instead of just colors to distinguish player groups, ability to hide some of the groups)
| done
|-
| 14
| Advanced userlist
| OPTIONAL
| Implement all the outlined upgrades to the player list, with icons, nice interface for hiding groups, sorting options, possibly being able to hide the player list entirely.
| done
|-
| 15
| Lobby mode switching
| OPTIONAL
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.
| 0%, delayed
|-
| 16
| Server RNG prototype
| MANDATORY
| Write a simple RNG service in wesnothd. Write a simple server-rng-using RNG in the client. Wire it up to do combats and test. If not feasible, write a descriription of the problems encountered.
| done
|-
| 16.5
| MP protocol cleanups
| OPTIONAL
| Clean up what the server sends to the client esp. in regard to game info to avoid some pointless tricks
| 0%, delayed
|-
| -
| 3rd milestone
| MILESTONE
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.
| done
|-
| 17
| Simple wesnoth-less moderation
| MANDATORY
| Write "a" way of moderating wesnotd without launching the game. Could involve having to type a special password with each privmsg command to the lobby bot, but should work.
| done
|-
| 18
| Advanced wesnoth-less moderation
| OPTIONAL
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.
| done
|-
| 19
| Full server RNG
| OPTIONAL
| If the prototype is successful, wire all random numbers to use it, make it robust.
| 20% groundwork laid
|-
| 20
| General polishing
| MANDATORY
| Touch up various areas of the code, especially make sure the gui behaves nicely.
| 50%
|-
| -
| 4th milestone (final)
| MILESTONE
| Have the project in a working and polished state by August <strike>15</strike> 10.
| looking good
|}

==Remaining issues==
[M] - Mordante, [I] - Ilor, [O] - other people
===Blockers===
* [M] The mouse focus dynamic cast fail (tm) discovered by Soliton. Confirmed and being worked on by Mordante [Fixed in 1.7.3]
* [I/M] The log in to trunk, try logging into 1.7 server assert discovered by me, I need to get more info as it seems difficult to reproduce. [Fixed in 1.7.3]
* [M] Resizing is not reliable, resizing down can result in an exception and a drop to titlescreen if there's not enough space; resizing up can create garbage in the output (at least on winxp). Mordante notified and working on fix.

===Important===
* [M/I] Vertical layout jumpiness (stuff changes size as more games appear and more chat lines are in the log)
* [M] Tooltips don't work for icons inside a toggle panel
* [I] Room system needs docs and testing
===Other===
* [M] A wrapping widget container would allow some nice layout effects
* [I/O] Some icons desperately need changing
* [M] Buttons working inside a toggle panel would be nice
* [M] Scrollbars can appear for no particular reason
* [M/I] Not everything is tweakable in WML - color/formatting for friends, game status, some icons etc

==Practical considerations==
I have good knowledge of C++ (and STL), I'm moderately familiar with the Wesnoth codebase and I started to look into wesnothd sources. I learned C++ pretty much on my own, first by coding small problems for some local programming/algorithm contests. I even got to the country finals once, though I'm not a huge fan of 5-hour "reimplement the appropriate algorithm in each of the problems" events. At least this made me pay attention to computational etc. complexity issues. Later I got some more useful knowledge from various books and experimenting. I'm comfortable with Subversion and intent on finally trying git-svn. I develop mainly on windows on MSVC but can switch to linux if it turns out toying with wesnothd is problematic on windows.

I use MSVC mainly because it's a powerful and helpful tool, though not without defects. I also use a lightweight smart text editor (notepad++) for general editing. Cygwin, putty, wireshark are some useful tools I use quite often.
I am awake between around 0900 UTC and 0100 UTC, and online for an hour or two in the mornings and for most of the evening/night. I can sometimes be reached during the day on IRC if the campus wifi works good enough and I have my laptop with me. No objections towards talking on thephone, voip on whatnot, in English or Polish.

As I'm a student in Europe, I will have a lot of exams at the end of May and in the first half of June, and will not be able to do much work during that time. I will be generally available, just busy. I plan to offset this by doing some work during the "community bonding" period and, well, working hard in general :). This is also why I give myself quite a lot of time between the program start and the first item on the timeline.

[[Category:Summer of Code]]

Wesnoth1.8Features

2009-08-06T18:19:11Z

SkeletonCrew: /* Mordante */ updated the status

=Stuff people are working on=
== Mordante ==
=== Will complete ===
* Polish cmake into a good working state (in progress)
* Various improvements to the new gui
* Finish the new in game dialog (http://www.wesnoth.org/forum/viewtopic.php?f=18&t=25585)
* Finish the bugs in the lobby (items marked with [M] http://www.wesnoth.org/wiki/MP_Server_Ilor#Remaining_issues)
* Rewrite the layout algorithm (in progress)

=== Wants to complete ===
* Rewrite the tooltips
* Add new widgets
** horizontal listbox
** look at horizontal and vertical grids
* Finish the new widget system
* Open bugs assigned to me

=== Hopes to complete ===
* Open FRs assigned to me

=== Completed ===
* Improve campaign selection dialog (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497655) (Note there are some problems so it might be that this gets postponed until 1.7.)

=References=

[[TextdomainStatus|current status of textdomains]]

[http://bugs.wesnoth.org bugs.wesnoth.org] - List of known and reported bugs

[[Category:Development]]

EasyCoding

2009-07-19T17:02:21Z

SkeletonCrew: /* GUI2 related features */ Remove a tasks, which easy part has been done

== Foreword ==
This page is here to document easy to do coding tasks. It is not here to double the feature request database, and should only be filled by people that know the code well enough to judge the difficulty of a given task.

If you are such a person, you should feel free to edit this page.

If you're not, you should post a feature request and discuss your idea on the forum or IRC. A coder with better knowledge of the code might give you the green light to add your feature here.

Anybody should feel free to add "clues" to any tasks, that is entry points, traps to avoid, person to contact to discuss and so on.

If you plan to work on a feature, write your name at the bottom of the feature, with the date. Note that if you are too long at working on a feature I'll "free" it back (that is if you're not working on it. If you have problems implementing it, just tell us....)

--[[User:Boucman|Boucman]] 20:48, 3 October 2006 (CEST)

Since bugs are sometimes a good opportunity to get a first idea of the code, i will add some here that are easy to fix as soon as i stumble upon them (the one i had in mind is fixed already ;-).

--Yogi Bear, 28 February 2008

== MP related features ==

=== Use different font for in-game chat ===
Since commas and dots are apparently hard to tell apart. As per FR #7470 [https://gna.org/bugs/?7470]

== WML related features ==

=== WML configurable village income / upkeep ===
Preferably as a [scenario], [side] or [campaign] keys. As per FR #6301 [https://gna.org/bugs/?6301]. Patch submitted: [https://gna.org/patch/index.php?1162] (gabba)

=== Add support of [if] for [scenario] ===
As per FR #4539 [https://gna.org/bugs/?4539]

=== Make [have_unit] optionaly use full SUF ===
[have_unit] by default uses SUF but does not apply it to recall list. Introduce an optional key that will allow to lift that limitation.

=== Side-specific results ===
Giving result=defeat or result=victory for specific sides. ([http://gna.org/bugs/index.php?4960 FR #4960]) -- [[User:dlr365|dlr365]] -- patch submitted [https://gna.org/bugs/index.php?4960]

=== Support for leaderless multiplayergames ===
Add support for the WML key victory_when_enemies_defeated= in the scenario tag during multiplayergames. ([https://gna.org/bugs/index.php?8106 FR #8106])

=== Support for standalone multiplayer scenarios ===
There used to be support for standalone scenarios in the userdata tree, in reorganising the trees this feature got lost and an add-on is now required to add a scenario.
Re-add this feature. It is probably a good idea to mirror the mainline multiplayer tree.

=== Other Ideas ===
See [[FutureWML]]; some ideas there are easier than others.

== Improvements to FormulaAI ==

Add new formula functions, or minor improvements to the formula language. Make it easier to debug the formula language.

Please discuss these with Dragonking, Sirp or Boucman

Use [[AI_Arena]] for testing custom formulas.

=== Poisoning Improvement ===

Writing a formula that will make units with poison attacks prioritize their targets to spead poison as much as possible, avoiding already poisoned units and other useless targets

=== About to level formula ===

Writing a formula that would handle units with only a few XP left to level and have them fight accordingly (most likely to kill or hit depending on XP needed, taking into account target's level)

=== Healer improvements ===

Handle units with healing power, moving them at places where they can provide the most healing

=== Leader improvements ===

A bit more complicated : special handling of units with leadership to have them support units. Only do it if it actually is usefull (less hits needed to kill the unit) and ability to help multiple units in a single turn (assuming enough MP)

=== Berserker improvements ===

The default AI's strategy of attacking as much as possible is very bad with berserker... A simple AI that would prevent the berserker from attacking (and keeping him close to fight without being exposed) and attack when the chance to kill is high enough would be an interesting addition

=== Debugging help ===

<s>* provide a way for a formula to have a text float over hex (for debugging purpose).</s> done by [[SummerOfCodeProposal_AI_Improvement_Crab|Crab]], patch submitted [https://gna.org/bugs/?13230]
* in debug mode, have all AI move print their name in the log

=== New type of candidate moves : Global ===

to be called only once with no implicit variable

== GUI related features ==
-------------------

Note at the moment Mordante is working on a new GUI system, these
changes will probably affect the way these items need to be implemented.
Contact Mordante on IRC before starting to work on these.

--[[User:SkeletonCrew|SkeletonCrew]] 14:04, 9 March 2008 (EDT)

=== Theme Changes ===

* allow custom themes to display values of WML variables ([http://gna.org/bugs/index.php?6209 FR #6209])
* hide the hourglass item from the statusbar when there is no timer

=== Widget Changes ===
* show side number, name and team association information in the status table
* make games sortable in the lobby (open slots, total number of players, era, XP modifier, gold per village, fog/shroud)
* input history (chat, commands, ..) - note: rujasu is working on this feature

== GUI2 related features ==
GUI2 is the new gui engine Mordante/SkeletonCrew is working on.
* Information on the wiki can be found here http://www.wesnoth.org/wiki/GUIToolkit
* The source code is under src/gui/
* The configuration config files are under data/gui/default

Some tasks need the --new-widgets since the code is only shown in the experimental mode. Tasks which need this switch have the * in the title.

=== * Savegame dialog ===
This is a new dialog to write and requires the minimap code to be fixed first. The dialog should mimic the current dialog. Sorting of a listbox and the proper alignment of the columns is not important (the engine doesn't support this yet). The code should only be used when --new-widgets is used as start switch since we're in a feature freeze at the moment.

=== Arrow keys for the slider ===
There's a new slider widget, but it doesn't support the keyboard yet.
gui/widgets/slider.[c|h]pp

Clicking on the widget should capture the keyboard and then arrow left/right should move one step even if not all steps are visible.

=== Slider sizing ===
There are some issues with the sizing of a slider.
gui/widgets/slider.[c|h]pp

In a layout step it needs to try to shrink itself, not entirely sure where or how yet, best ask mordante on irc.

<del>

== Savegame related stuff ==

=== consistent player information ===
At the moment, the [player]-section for a campaign savegame will appear in two places: The root level of the savegame and the [replay_start]-section. This was due to a last-minute fix for 1.6 that was designed to be the least intrusive. The [player]-section should only be written to [replay_start] (and of course read from there as well). Patch submitted: [https://gna.org/patch/index.php?1150] -grantwu

=== fix bug #13268 (save corruption through undo/redo of recalls [https://gna.org/bugs/?13268] ===
</del>

== Miscellaneous ==

=== More powerful village naming ===
'''Adding mountain names and other features to village names, having a second random name in village names'''

Currently the village naming engine has a very good structure that could allow
more powerfull names to be generated.
Understanding how it works should be quite easy, and a few usefull improvements could be added.

* Currently villages can use lake names and river names, this should be extended to other features like bridges, swamps, mountains etc...
* It would be nice to have a separate list of "first sylabus" and "last sylabus" for naming. That's not really needed in english, but some translations could use it
* Again, it is common to have villages with more than one "random" word in them. having a $name2 variable would be nice

Euschn 24/03/2009

=== Debug Mode ===
* New debug command functionality (setting additional status.variables, possibly terrain)

== Bugs ==

== See Also ==

[[NotSoEasyCoding]]

[[Category:Development]]
[[Category:Future]]

Wesnoth1.8Features

2009-06-13T14:40:46Z

SkeletonCrew: /* Mordante */ Status update

=Stuff people are working on=
== Mordante ==
=== Will complete ===
* Polish cmake into a good working state
* Various improvements to the new gui
* Add new dialog to show the transparent portraits Kitty made. (ready for test, still needs the touch of an artist)

=== Wants to complete ===
* Finish the new widget
* Open bugs assigned to me

=== Hopes to complete ===
* Open FRs assigned to me

=== Completed ===
* Improve campaign selection dialog (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497655) (Note there are some problems so it might be that this gets postponed until 1.7.)

=References=

[[TextdomainStatus|current status of textdomains]]

[http://bugs.wesnoth.org bugs.wesnoth.org] - List of known and reported bugs

[[Category:Development]]

EasyCoding

2009-05-13T19:43:17Z

SkeletonCrew: /* GUI2 related features */ Remove a completed task

== Foreword ==
This page is here to document easy to do coding tasks. It is not here to double the feature request database, and should only be filled by people that know the code well enough to judge the difficulty of a given task.

If you are such a person, you should feel free to edit this page.

If you're not, you should post a feature request and discuss your idea on the forum or IRC. A coder with better knowledge of the code might give you the green light to add your feature here.

Anybody should feel free to add "clues" to any tasks, that is entry points, traps to avoid, person to contact to discuss and so on.

If you plan to work on a feature, write your name at the bottom of the feature, with the date. Note that if you are too long at working on a feature I'll "free" it back (that is if you're not working on it. If you have problems implementing it, just tell us....)

--[[User:Boucman|Boucman]] 20:48, 3 October 2006 (CEST)

Since bugs are sometimes a good opportunity to get a first idea of the code, i will add some here that are easy to fix as soon as i stumble upon them (the one i had in mind is fixed already ;-).

--Yogi Bear, 28 February 2008

== MP related features ==

=== Use different font for in-game chat ===
Since commas and dots are apparently hard to tell apart. As per FR #7470 [https://gna.org/bugs/?7470]

== WML related features ==

=== WML configurable village income / upkeep ===
Preferably as a [scenario], [side] or [campaign] keys. As per FR #6301 [https://gna.org/bugs/?6301]. Patch submitted: [https://gna.org/patch/index.php?1162] (gabba)

=== Add support of [if] for [scenario] ===
As per FR #4539 [https://gna.org/bugs/?4539]

=== Make [have_unit] optionaly use full SUF ===
[have_unit] by default uses SUF but does not apply it to recall list. Introduce an optional key that will allow to lift that limitation.

=== Side-specific results ===
Giving result=defeat or result=victory for specific sides. ([http://gna.org/bugs/index.php?4960 FR #4960]) -- [[User:dlr365|dlr365]] -- patch submitted [https://gna.org/bugs/index.php?4960]

=== Support for leaderless multiplayergames ===
Add support for the WML key victory_when_enemies_defeated= in the scenario tag during multiplayergames. ([https://gna.org/bugs/index.php?8106 FR #8106])

=== Support for standalone multiplayer scenarios ===
There used to be support for standalone scenarios in the userdata tree, in reorganising the trees this feature got lost and an add-on is now required to add a scenario.
Re-add this feature. It is probably a good idea to mirror the mainline multiplayer tree.

=== Other Ideas ===
See [[FutureWML]]; some ideas there are easier than others.

== Improvements to FormulaAI ==

Add new formula functions, or minor improvements to the formula language. Make it easier to debug the formula language.

Please discuss these with Dragonking, Sirp or Boucman

Use [[AI_Arena]] for testing custom formulas.

=== Poisoning Improvement ===

Writing a formula that will make units with poison attacks prioritize their targets to spead poison as much as possible, avoiding already poisoned units and other useless targets

=== About to level formula ===

Writing a formula that would handle units with only a few XP left to level and have them fight accordingly (most likely to kill or hit depending on XP needed, taking into account target's level)

=== Healer improvements ===

Handle units with healing power, moving them at places where they can provide the most healing

=== Leader improvements ===

A bit more complicated : special handling of units with leadership to have them support units. Only do it if it actually is usefull (less hits needed to kill the unit) and ability to help multiple units in a single turn (assuming enough MP)

=== Berserker improvements ===

The default AI's strategy of attacking as much as possible is very bad with berserker... A simple AI that would prevent the berserker from attacking (and keeping him close to fight without being exposed) and attack when the chance to kill is high enough would be an interesting addition

=== Debugging help ===

<s>* provide a way for a formula to have a text float over hex (for debugging purpose).</s> done by [[SummerOfCodeProposal_AI_Improvement_Crab|Crab]], patch submitted [https://gna.org/bugs/?13230]
* in debug mode, have all AI move print their name in the log

=== New type of candidate moves : Global ===

to be called only once with no implicit variable

== GUI related features ==
-------------------

Note at the moment Mordante is working on a new GUI system, these
changes will probably affect the way these items need to be implemented.
Contact Mordante on IRC before starting to work on these.

--[[User:SkeletonCrew|SkeletonCrew]] 14:04, 9 March 2008 (EDT)

=== Theme Changes ===

* allow custom themes to display values of WML variables ([http://gna.org/bugs/index.php?6209 FR #6209])
* hide the hourglass item from the statusbar when there is no timer

=== Widget Changes ===
* show side number, name and team association information in the status table
* make games sortable in the lobby (open slots, total number of players, era, XP modifier, gold per village, fog/shroud)
* input history (chat, commands, ..) - note: rujasu is working on this feature

== GUI2 related features ==
GUI2 is the new gui engine Mordante/SkeletonCrew is working on.
* Information on the wiki can be found here http://www.wesnoth.org/wiki/GUIToolkit
* The source code is under src/gui/
* The configuration config files are under data/gui/default

Some tasks need the --new-widgets since the code is only shown in the experimental mode. Tasks which need this switch have the * in the title.

=== * Savegame dialog ===
This is a new dialog to write and requires the minimap code to be fixed first. The dialog should mimic the current dialog. Sorting of a listbox and the proper alignment of the columns is not important (the engine doesn't support this yet). The code should only be used when --new-widgets is used as start switch since we're in a feature freeze at the moment.

=== * Title screen ===
A start has been made for the new titlescreen
* src/gui/dialogs/title_screen.[c|h]pp
* data/gui/default/window/title_screen.cfg
This should be improved to include the buttons and alignment of the current title screen. The 'roll-over' image is not part of this task.

=== Arrow keys for the slider ===
There's a new slider widget, but it doesn't support the keyboard yet.
gui/widgets/slider.[c|h]pp

Clicking on the widget should capture the keyboard and then arrow left/right should move one step even if not all steps are visible.

=== Slider sizing ===
There are some issues with the sizing of a slider.
gui/widgets/slider.[c|h]pp

In a layout step it needs to try to shrink itself, not entirely sure where or how yet, best ask mordante on irc.

<del>

== Savegame related stuff ==

=== consistent player information ===
At the moment, the [player]-section for a campaign savegame will appear in two places: The root level of the savegame and the [replay_start]-section. This was due to a last-minute fix for 1.6 that was designed to be the least intrusive. The [player]-section should only be written to [replay_start] (and of course read from there as well). Patch submitted: [https://gna.org/patch/index.php?1150] -grantwu

=== fix bug #13268 (save corruption through undo/redo of recalls [https://gna.org/bugs/?13268] ===
</del>

== Miscellaneous ==

=== More powerful village naming ===
'''Adding mountain names and other features to village names, having a second random name in village names'''

Currently the village naming engine has a very good structure that could allow
more powerfull names to be generated.
Understanding how it works should be quite easy, and a few usefull improvements could be added.

* Currently villages can use lake names and river names, this should be extended to other features like bridges, swamps, mountains etc...
* It would be nice to have a separate list of "first sylabus" and "last sylabus" for naming. That's not really needed in english, but some translations could use it
* Again, it is common to have villages with more than one "random" word in them. having a $name2 variable would be nice

Euschn 24/03/2009

=== Debug Mode ===
* New debug command functionality (setting additional status.variables, possibly terrain)

== Bugs ==

== See Also ==

[[NotSoEasyCoding]]

[[Category:Development]]
[[Category:Future]]