Merge lp://staging/~widelands-dev/widelands/bug-1191295-no-seafaring-builder into lp://staging/widelands

Code LGTM so far - will have to look into the saveloading thing.

Continuous integration builds have changed state:

Travis build 1871. State: passed. Details: https://travis-ci.org/widelands/widelands/builds/195007413.
Appveyor build 1708. State: success. Details: https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_bug_1191295_no_seafaring_builder-1708.

I think I found a (at least prettier) solution for the problem:

- Increase the packet number ob the portdock without changing anything else in the class. There can't be an expedition without a portdock and the dock is loaded first. So old games will fail gracefully when loading the new save game.
- Implement the above hack in the expedition. New games are then able to load new and old files, old games never come this far.

Note: I haven't tried out anything yet.

Increasing the version number of the portdock is a good idea. Rather than the ugly hack, you could pass the version number of the portdock to the load function.

You could also check if you can still separate wares from workers in a way that allows you to keep the save format, as long as we don't end up with overcomplicated code.

Games from Build 19 should still load after this change too.

I guess I could implement a version which does not change the save file format. However, this would mean:
a) Open up some internals (mainly the request-object) of the WorkersQueue class to the expedition class
b) Would only work as long as the number of workers is either 0 or 1
So it would be possible, but I like it even less than the hack*.

Passing the version number (of the stored packet, I guess?) isn't that easy since both the loading code of the portdock as well as the loading code for the expedition are called from MapBuildingdataPacket::read_warehouse(). I think it should be possible to run the loading code for the expedition from inside the portdock-loading, but I haven't tried it yet. I am not that happy moving the call but it is the best version I have found yet.

General question: We only offer compatibility for old save games with new game versions, right? So a new save game does not have to be loadable by an old game version (and isn't anyway due to the barracks and probably other changes).

* I shouldn't have called it that. Maybe call it "creative data usage"? When I would have implemented it quietly this branch would have already been merged. ;-)

We broke savegame compatibility with Build19, but that was an exception. So, we are supporting savegames for Build19 and newer again now.

Adding a lot of complicated code for avoiding the hack is a -1, we should only have done it if the extra code needed was small.

How about tying it to kCurrentPacketVersionWarehouse? I don't see any code in portdock to load the expedition bootstrap, so tying it to the warehouse version number in MapBuildingdataPacket::read_warehouse() should be fine.

Continuous integration builds have changed state:

Travis build 1897. State: failed. Details: https://travis-ci.org/widelands/widelands/builds/197571337.
Appveyor build 1732. State: success. Details: https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_bug_1191295_no_seafaring_builder-1732.

Well, those who can read ...

After some failed approaches I ended up with the creative data usage, just to push it and see your comment. Thanks for the hint with the warehouse packet version, I missed that one but I am using it now.

Loading old expedition packets is not as pretty as I would like it to be, but it seems to work. Displaying, saving and loading of the expedition builder should work now.

Continuous integration builds have changed state:

Travis build 1900. State: passed. Details: https://travis-ci.org/widelands/widelands/builds/197785098.
Appveyor build 1735. State: success. Details: https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_bug_1191295_no_seafaring_builder-1735.

I can't come up with any less ugly hack. I'll do some testing.

@bunnybot merge