Fosdem2011

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

(nick)name(s)	Arrival	Departure	Accomodation
AI, mordante	Fri, 4th (at ULB ~15:00)	Sun, 6th	2go4, booked by Ivanovic, 4-bed room
Boucman	Fri, 4th (midi station 17:33)	Sun, 6th	2go4, booked
Crab_	Fri, 4th (airport arrival 18:45)	Tue, 8th	2go4, booked
elias	Fri, 4th (airport arrival 12:15)	Sun, 6th	BestWestern, booked
fendrin	Fri, 4th (central station 14:30)	Sun, 6th	2go4, booked by Ivanovic, 4-bed room
grzywacz	Fri, 4th (airport charleroi ETA 20:35)	Sun, 6th	2go4, booked
Ivanovic & chrber	Fri, 4th, "afternoon" (~15:00 at "chokopolis")	Sun, 6th, leaving right from ULB campus	2go4, booked by Ivanovic, 4-bed room
Sirp & Dragonking	Fri, 4th, (airport arrival 17:00)	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!):

• CHAB
• 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...
• Bruegel YH

On the official FOSDEM page some more possible hotels/hostels are listed.

Maps

• Bruegel YH
• Brussels Central (Train Station) → Bruegel YH
• Bruegel YH → Brussels Central (Train Station) → Novotel Grand Place
• Novotel Grand Place
• CrownePlaza (Europa)
• FOSDEM
• Novotel Grand Place -> FOSDEM

Transportation

Information about how to reach the FOSDEM is listed at the 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

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.

FOSDEM 2012

Basic question was if developers are interested in going to the next FOSDEM (the answer was a clear yes). Another question was if we should try to go for a complete dev room. The benefit of having a dev room would be that we had it just for us (plus people who are interested in listening to our stuff. In the room we should be holding talks (eg about stuff like "how to create artwork for an open game" (possibly including a live example about how it can be done) or "how to successfully start an open source game") but could also have discussions as well as hacking sessions. General agreement was that this step would make sense and that we might also consider talking to other orgs (gaming related ones!) if they are interested in this and want to join us to make it an "Open Source Gaming Dev" room with all the thing required for open games (since it is not about only having coders but also graphics, music/sounds, campaigns and story as well as translations.

GCI 2010/1011

We talked if we thought that GCI was a success for us and if we should consider trying to repeat it (if possible. In general the conclusion was that we were positively surprised by the contest. Both the quality of the work submitted as well as the tasks completed were really surprisingly good. We think that we should go for another round in case we do meet the requirements (this year it was required to participate in GSOC and it is not sure yet if we will be accepted there again). The general thing that we should change is that we should provide more coding and artwork related tasks. This is not of immediate concern since the next GCI won't start before GSOC is over, more likely it will start close to Christmas.

GSOC 2011

One question asked was if we wanted to participate in the new GSOC. The basic decision was that it would make sense to do so as long as we got projects as well as willing mentors. Some people already volunteered to consider being mentors and we still have some reasonable project ideas left from last year. One general comment was that we should make the projects a little smaller than they were so far. Besides we should shift our requirements to include more documentation, meaning that the ratio between code produced and documentation created shifts more to documentation.

Khalifate / New faction for mainline

We agreed that we do want to add the Khalifate to trunk as soon as possible. TSI reported that all the base frames should be basically done and we are just waiting for noy with the unit stats at the moment. Once we got those, the new faction "Khalifate" can be added to trunk. The current plan is to create a new era with the current setup named eg classic. This would basically be the factions with the balancing used in default up to 1.9.4. The default era (still named default) would have the Khalifate included. We do know that this will extremely unbalance the default era, but this way we make sure that the Khalifate will get testing from our users. Then we got about 9 month to find a usable balance till we start a new stable series.

Users in IRC raised concerns regarding the balancing (mentioned above already, it won't be perfect at the start and has to improve over time, but requires lots of playtesting to do so), creation of the unit cfgs (should be done in about an hour, once we got the actual values!) as well as the Khalifate being too "real world" (are they really some "real world stuff"? Personally some Arabic/Mongolian themed stuff does fit nicely into a game like Wesnoth, too.

Basic result of the discussion with the devs that were around at FOSEM was that it should be in trunk as soon as possible, so that it might be already available in the next dev release 1.9.5.

Licensing problems

On the mailing list the problem of Wesnoth licensing and possible incompatibility with web stores like eg the appstore from Apple for the iOS stuff (iphone, ipod touch and ipad) was brought up. The discussions on the mailing list were rather heated so it of course was a topic that we had to talk about during FOSDEM. The developers present felt that their prime concern is that the code is available freely, that it can be redistributed and recompiled. Generally we do think that the appstores that allow this are most likely compatible with the philosophy we have for Wesnoth.

We also decided that the Wesnoth developers may officially endorse a port if we feel that it is basically done in a way that it is beneficial to the Wesnoth community. These are basically the important points:

• They have to link back to wesnoth.org.
• Their code has to be in a public repository.
• If the port is redistributed for a fee, then a portion of the revenue has to be shared with the project.

Lord of Music

Lately we had the problem that we lost our Lord of Music West. We still have another Lord of Music in the team who is still active in the forums: Tyler Johnson. We plan to encourage him to take a more active role and communicate with us once something is ready for commit.

Multiplayer (campaign) UI

Fendrin brought up that the current GUI does suck for creating multiplayer campaign games. Several changes are required to make it work nicely. Fendrin and YogiHH worked on creating a proposal how stuff *could* be done. Here is a short list of problems and possible solutions:

Display of campaigns in scenario selection

Currently the interface does display the multiplayer campaign "Legend of Wesmere" at the very bottom of the list, even after some additional stuff like the test/benchmark scenarios. It would make sense to redesign the system to eg show tabs that allows differing between "simple scenarios" and "story based cooperative gameplay". The basic difference between those two is also that the information shown has to differ. For scenario you have tunable setting (village gold, starting gold, experience modifier, ...) while for a campaign you should rely on the author regarding the balancing.

Difficulty levels for MP campaigns

Currently all MP content has to be parsed before joining the server. This means all difficulty levels of a campaign would have to be parsed before you can even see it in the list. This somehow sucks. Sadly just loading (aka reparsing) the config after selecting it in the menu is currently not possible because you will end with a ping timeout.

• Testing with a 300 second sleep didn't result in a timeout, so this may not be a big issue.

Split config cache for MP data

Currently all MP content has to be completely parsed before being able to join the MP server. This leads to several problems:

• Once you download a new addon the *complete* cache has to be reparsed and redone. This leads to a huge (useless!) overhead.
• It is not possible to do lazy loading.
• Some addons do conflict. If they are all in one Cache, they simply create ugly problems.

A possible fix for the problem would be splitting the cache into domains like it is done for singleplayer campaigns. This would eg lead to a new config file for a new faction, but the old config files would not change. With this approach we would have to probably create all config files before joining the server, too, but we would not just create one file but several. Then refreshing the cache would mean that only a fraction of the whole stuff is recreated. Which should speed stuff up when joining the mp server after getting new content.

Spritesheets

TSI brought up the matter of sprite sheets. We talked about how spritesheets are done in frogatto and that it might make sense to implement them in Wesnoth, too, but we first need someone to do it and it has to be done in concert with the artists to find the most usable way for them.

Wesnoth 1.10

So far there was no decision when to release the next stable release. Since we want to participate in GSOC and students are meant to directly commit their work to trunk and it has to be open for "new stuff". After GSOC we also need some time to fix bugs and polish new things, so the current idea is the next stable should be created around Christmas. In general we cannot release 1.10 anytime close since it is not as stable as we would require it (just have a look at the amounts of bugs currently reported in the tracker!). So the next month should also be used for polishing as well as adding new stuff.

Discussions in sub groups

Easing the use of lazy loading/modding

Currently at game start a whole lot of content has to be parsed. For the campaigns we do rely on a system where we only parse the _main.cfg file and the rest later on when the campaign and the wanted difficulty level were selected. The idea is that adding a general config block (maybe some "manifest" file) would help to provide the basic list that should be fast to parse and keep in memory. This manifest file would work similar to the current _main.cfg files. It could provide some basic information that is always required, even if you don't start the stuff and it would include a type entry plus possibly dependencies on content. A later step could be offering some "module manager" where you select which things you do want to have active. So that you maybe don't want all the addons you downloaded available from the start. Or that you want to use a conversion of the ruleset to do some strange things. Part of this discussion were chrber, fendrin, Ivanovic, Mordante, YogiHH and possibly several others.

tinygui

gnutoo (who is also around in IRC every now and then) visited us in the (Wesnoth) Hacking Room. With him he brought some Linux based mobile devices. One of the devices was a N900 with an 800x480 screen and specs rather similar to the OpenPandora (Ivanovic is creating packages for this device). Wesnoth seems to run nicely on this one, though the screen is even smaller (~3" on the N900 vs 4.3" on the OpenPandora) so using it (only with the touchscreen) is even more difficult. He also brought a phone with some "smaller" screen running some Wesnoth version that had rely on tinygui. It looked really tiny and had (again) severe graphic problems. Because it is de facto not supported by any dev and tends to break regularly (if things get fixed at all!) Ivanovic proposes the complete removal of tinygui. This would (for the moment) mean that support for any resolutions <800x480 would be gone (currently it is rather hackish anyway). Mordante mentioned that once everything is converted to GUI2 (no timeline available for this task!) it should be possible to do the whole gui stuff in a more sane way so that it does work nicely for "really small resolutions", too. Once we have some OpenGL support added (yeah, once we find someone to actually do the job, the move to OpenGL is still a plan) it should also be possible to implement some "better" zooming that helps modern day devices to increase/decrease size as it fits.

Group Picture

(Big version) Annotated for your convenience! - tsi

FOSDEM 2010

We were already at FOSDEM 2010, here something as reference:

• FOSDEM 2010 wiki page

FOSDEM 2009

We were already at FOSDEM 2009, here something as reference:

• FOSDEM 2009 wiki page

FOSDEM 2008

We were already at FOSDEM 2008, here something as reference:

• Forum topic (with group photo)
• 2008 wiki page
• Summary of FOSDEM 2008 results