rowboat/ferry

[Perkins]

Ships are nice, but they have a restricted set of destinations and are big and slow.

It might add some realism to have the shipyard able to also produce smaller boats capable of crossing short stretches of water (like across a river). The range limit could be hard-coded, set per map, or done by adding a chance of a boating accident per unit of distance traveled. Personally I'd lean toward that last one. Accidents could range from goods falling overboard to losing the entire boat and its contents. This would give an incentive to use land routes unless the water route is significantly shorter, and leave a use-case for adding bridges later.

A starting suggestion for capacity would be to make it half the speed of a carrier on land, but able to move three items at once. This puts it as slightly more efficient than a carrier, slightly less efficient than a carrier + animal, and the odds of a mishap can be adjusted (possibly per map, or even per terrain type if multiple types of water ever get implemented) to keep the practical distance relatively short for balance purposes.

This might require some adjustments to maps for balance purposes, but not as much as one might think since one would need to be able to build something on the far shore anyway for crossing a river to make much of a strategic difference. The only serious consideration would be whether troops could cross the river in boats and attack structures that would otherwise be out of reach, and whether troops on land should get a bonus against those disembarking.

I do recall there being rowboats in Settlers 2. In that case the maps were all carefully designed to only have a few places where they were useful.

[kaputtnik (franku)]

Yes, this has been discussed some time ago, see https://wl.widelands.org/forum/topic/1648/ (Rivers and Bridges).

Implementing this is maybe a task for build 20 :-)

[Benedikt Straub (nordfriese)]

I´m hoping to get this done for build 20 :)
See also https://wl.widelands.org/forum/topic/4293/ for (planned) implementation details

[Benedikt Straub (nordfriese)]

A first preview for the waterways along which ferries will travel :)

[Benedikt Straub (nordfriese)]

This will likely not be ready for build 20, the branch is infested with new bugs :(

[Benedikt Straub (nordfriese)]

Some progress

[Teppo Mäenpää (kxq)]

Ferries probably break many maps (= the way they were intended to be played). Therefore, I would *not* like to see ferries going to trunk just before freeze.

Would it be easy to put ferries around a conditional (so that they would be prevented on some maps)?

[Teppo Mäenpää (kxq)]

I tried to try this, but got segfaults quite often. I suppose that you have enough backtraces?

Please do not read the above comment wrong. I my intention was to demote this enhancement.

[Teppo Mäenpää (kxq)]

.. was NOT to ..

Terribly sorry, slips like this should not happen.

[GunChleoc (gunchleoc)]

Re #6: We don't want to add big new features at this point anyway. We already have plenty of feature goodies for Build 20, what we need to do now is fix bugs ;)

So, this feature is definitely targeted for Build 21.

[Benedikt Straub (nordfriese)]

Another screenshot

[Benedikt Straub (nordfriese)]

A simple testcase for ferries

[kaputtnik (franku)]

The attached save game has two waterways which never get a ferry. One starting at flag 93/108, the other one starting at flag 115/114. I think this is because the ferries can't reach the waterways, because a ferry can't boat where the landtiles are too close, although the ferries are very small.

This is very disturbing. I think a player do not understand this behavior. This may lead into several Questions in the forum. If we have ferryboats as wares, a carrier can grab the boat from the warehouse and can walk to the destination, although if it would be otherwise unreachable. Other ideas?

The ferries should also get direction related images. Seeing a ferry boating north east and the bow is pointing to south east is disturbing too.

[kaputtnik (franku)]

We may also need a new tutorial, or extend an existing one, to explain how the ferries work. At least it should explain that ferries do only transport wares and no workers, so one has to connect a construction site with normal roads to get a builder there. Maybe the seafaring tutorial is good for this?

[GunChleoc (gunchleoc)]

Agreed on having a tutorial. We should do that in a separate branch though.

[Benedikt Straub (nordfriese)]

Ferries are like ships: They can sail only on open water, able to touch a corner of land if both adjacent nodes are open sea. So the behaviour obeserved in the savegame is correct.
I see two ways of fixing this:
 – Making ferries a ware like you suggested, that is carried to the new waterway by a worker and then the carrier plus the ware ferry turns into a real ferry. This might be not too hard to implement, but it could be more tricky than it seems. And it´ll likely introduce a whole set of new bugs into this branch just after I fixed all I could find. What should happen when the waterway is destroyed? The ferry looks for a flag, and when it finds one, it turns into carrier + ware again? And if it doesn´t find one for some time, it´ll sink?
 – Or ferries are allowed to travel along any edge where both adjacent triangles are navigable. This would involve quite some code duplication, because ship fleets and ferry fleets would then be two separate things. It would be less likely to introduce many new bugs though.

The animations of the ferries were deleted on GunChleoc´s request to make the diff easier to read ;) They´ll be re-added before merging, and proper animations will be created later. I´m planning to make a follow-up branch when this is merged that includes an addition to the seafaring tutorial and proper graphics for ferries and ferry yards (at least for fri, not sure about the other tribes…).

[kaputtnik (franku)]

Thanks for the clarifications :)

> – Or ferries are allowed to travel along any edge where both adjacent triangles are navigable.

Because the ferries are very small, i had expected this. But i can imagine another issue with the current implementation and the above solution: A ferry can then be used to inspect some unknown land: Say having the Ferry yard near the headquarters and build some waterway on a far away spot. The ferry will then navigate along the coast (or use the shortest way) to get to his destination, probably revealing unknown land, at least for a short time. Some players do already use Woodcutters as a sort of Scout.

> – Making ferries a ware

In my opinion this would be a clear solution: It's like other wares which will be stored unless it is used by a production site.

> What should happen when the waterway is destroyed? The ferry looks for a flag, and when it finds one, it turns into carrier + ware again? And if it doesn't find one for some time, it´ll sink?

Yes to both. So it acts just like a ware (just remove the ferry)

This is just my personal opinion.

Nevertheless this is a great enhancement, thanks a lot for implementing this :-)

[Benedikt Straub (nordfriese)]

I´ll first try to implement the solution with relaxing the movement rules. This is easy and straightforward to program, I´m already waiting for the compiler. If it turns out that there are unforeseen difficulties with it, I´ll go for your suggestion of using a new ware. (This would mean rewriting a fairly large portion of code, that´s why I prefer the other one ;) )

> A ferry can then be used to inspect some unknown land

This is already the case (though less easy to use now). The same is true for most workers as well as ships (even without expeditions), just build your shipyard far away from the port and they´re useful scouts. So not really a reason against it IMHO…

[kaputtnik (franku)]

Ferries are much cheaper than ships. Whereas workers (like woodcutter, forrester or geologist) do act only on a small area, ferries may navigate a big distance.

Or should the ferry yard should have some kind of working area? So produced ferries will not navigate to a fleet which has both flags outside this working area. If one flag of the fleet is inside the working area, the whole fleet is considered inside the working area and the ferry navigate to it. Hm...

I'll wait until you're fine with the result and do some more testing.

[Teppo Mäenpää (kxq)]

I tried playing BZR8858 and it looked fine. However, after one hour or so, it crashed:
Game: Writing ai persistent data ... took 0ms
Game: Writing Command Queue Data ... took 1138ms
Game: Writing Interactive Player Data ... took 0ms
GameSaver::save() took 1481ms
SaveHandler::save_game() took 1481ms
Autosave: save took 1485 ms
widelands: ../src/economy/economy.cc:367: void Widelands::Economy::remove_wares(Widelands::DescriptionIndex, Widelands::Quantity): V�ite "type_ == wwWARE" ei pid� paikkaansa.
Aborted

For some reason, apparently I did not have debugging enables :-(

========

Anyway. Some opinions:

- Ferries as ware sounds nice.

- Inability to move workers can cause weird problems. For example, if an economy is split into two halves (called X and Z here), only connected by waterway: If X-side of the economy needs a new lumberjack, but all felling-axes are in a warehouse in the Z-side, what happens? Is the felling axe moved to X side as a result of this, and then converted to lumberjack? Does this cause mass production of lumberjacks on Z-side (unfulfilled request around..)? Does the picture change if there are no warehouses on X side? What actually is the reason not to carry workers in a ferry?

[Benedikt Straub (nordfriese)]

Regarding the last questions: The expected behaviour is that a felling axe will be brought from a warehouse in worker economy Z to a warehouse in worker economy X, where it´ll turn into a lumberjack.
(Note that there is one ware economy Y that encompasses all of X and Z.)
If no warehouse in X exists, no workers can be created in X, so nothing should happen.
I didn´t check yet what actually happens, thanks for bringing this up…

> What actually is the reason not to carry workers in a ferry?

– It makes ships obsolete on most maps where both are enabled
– It breaks design concepts of many maps, because you then could use ferries to access otherwise inaccessible territory (now you need a land or seafaring connection for ferries to be useful)
– It´s very, very hard to implement now without rewriting most of 11871 lines of code again ;)

Regarding the crash: I didn´t get that assert fail yet. Can you reproduce it? What did you just before it crashed?

If I implement the ferries-as-wares suggestion, it´ll probably follow these behaviour rules:
– Revert movement rules for ferries to the same rules as for ships, that is, you can build a waterway only on open sea with the exception that it may touch the shore if the adjacent node is ocean
– When the waterway is destroyed → look for a flag and turn into carrier + ware again; if no flag found for some time, sink
– I think the easiest way to implement the request is that one of the flags requests that a boat is carried to it. It´ll be carried there normally through the road/waterway/ports network. When it arrives, the flag additionally requests a carrier. Until he arrives, the boat lies around on the flag. When the carrier is there, carrier and boat turn into a ferry that assigns itself to the waterway.

Open Questions:
– By what rules should the waterway decide which of its two flags requests the ferry?
  e.g. always the flag from which it was built, or the flag where the nearest warehouse is closest, … (esp. important if the two flags are connected _only_ by the new waterway)
– What happens when splitting a waterway? Some maps will have tiny island (1 triangle) intended as ferry stops, but no carrier can ever arrive there. When splitting a waterway there, it´ll be not obvious whether the ferry will assign itself to the ww part that ends on the mainland or the part that is inaccessible. I don´t see a solution that will never cause frustration in such cases…

The last point is the main reason why I´m unhappy with this suggestion, and favour making the movement rules less strict instead. This already works fairly well; just chasing down a couple of regression bugs and then I´ll upload it.

[Teppo Mäenpää (kxq)]

> It makes ships obsolete on most maps where both are enabled

Yes, true for some maps.

>It breaks design concepts of many maps, because you then could use ferries to access >otherwise inaccessible territory

Very true. I think that for at least some old maps, ferries should be prohibited.

>It´s very, very hard to implement now without rewriting most of 11871 lines of code again ;)

This is a strong argument, and I buy it.

>By what rules should the waterway decide which of its two flags requests the ferry?

If I was writing this code, I would make something so simple that it is unlikely to have bugs. I have a feeling that there is already a way to convert co-ordinates into single integer. Just pick the smaller, for example. If somebody ever files a bug, then improve. If this was not the actual problem, please do not be offended.

> What happens when splitting a waterway? Some maps will have tiny island (1 triangle) intended as ferry stops, but no carrier can ever arrive there.

If there are no roads, is a carrier needed on that tiny island? If the flag on the tiny island is the one requesting the rowboat (assuming that rowboats would be wares), I see a possible problem.

>Regarding the crash: I didn´t get that assert fail yet. Can you reproduce it? What did you just before it crashed?

Reload a savegame (I attach one shortly). Immediately remove a flag at (75,18).

=====

Regarding rowboats as wares: The current system is not bad either. One can do limited scouting; I think that is OK. For player, the major difference is that you need to make rowboat maker separately for each pond if the boats work in current way; one boatyard suffices in boats as wares approach.

[Benedikt Straub (nordfriese)]

Thanks for the savegame, I found a function related to worker spawning that confused worker economies and ware economies. I removed lots of duplicate code and rewrote the function, but this breaks savegame compatibility to older branch versions yet again, so I can´t check if this is really fixed.
The new version is uploaded now, it still contains a few bugs related to ferry/waterway requests which I´ll fix soon.

[kaputtnik (franku)]

This is Widelands Version bzr8862[ferry] (Release)

On my slow laptop i create only release builds, so no gdb...
This save game crashes close after message:

Message: adding warehouse for player 4 at (115, 105)
Speicherzugriffsfehler (Speicherabzug geschrieben)

[Benedikt Straub (nordfriese)]

Thanks for reporting, the crash is fixed. The compiler seems to have tried to use ferry code for ship pathfinding because I had forgotten to rename a struct :S

[kaputtnik (franku)]

Thanks :-)

This save game has a waterway which did not get any ferry again.

[Benedikt Straub (nordfriese)]

Another one! Perhaps I should buy some good bug spray ;)
This one is tricky. The problem is that the FerryFleet that is responsible for distributing unemployed ferries to waterways *thinks* it is going to act() soon and therefore doesn´t need to schedule an act, but actually no act has been scheduled, so it´s now idling around forever.
Can you describe steps to reproduce this bug so I can investigate when exactly this happens?

[kaputtnik (franku)]

Sorry, i can't describe specific steps. Wouldn't the act() (whatever you mean by this) will be canceled if the waterway is destroyed and rebuild again?

All i can say: Trying to build any waterway in this particular bay will never demand a ferry, or: A ferry will never arrive at any waterway built in this bay. I have also removed all flags, roads and tried new waterways in this piece of ocean. The result is always the same: No ferry will arrive.

Yesterday i kept on playing this game building lots of waterways, but all new waterways got a ferry.

[Teppo Mäenpää (kxq)]

Doesn't the replay file document the steps taken?

[Benedikt Straub (nordfriese)]

Yes, I didn´t think of that :)
@kaputtnik: Do you still have a replay?

> Wouldn't the act() (whatever you mean by this) will be canceled if the waterway is destroyed and rebuild again?

I didn´t explain very well…
A FerryFleet is an abstract entity that keeps a list of all ferries and empty waterways that are within one ocean. It frequently needs to "think" (act), which means that it´s act() function is called, in which it distributes unemployed ferries to empty waterways. Adding a ferry or waterway calls the fleet´s update() function. update() asks the game to allow the fleet to act() soon – this permission-asking is necessary to avoid desyncs – but only if such permission hasn´t been granted ("scheduled") yet. This fleet believes for some reason that it is about to act(), so it will not request such permission from the game engine until the scheduled act() is over – essentially, this fleet now cannot act until after it has acted. I hope this is clearer…

[kaputtnik (franku)]

Sorry the replay is on my laptop which is only available on weekends. Maybe i can tell my girl friend to sent it to me.

Regarding your post in the merge request: I tested it and can confirm your observation. More over removing both waterways and rebuilding them (without adding an additional flag) solves the issue. I wonder why it didn't work on my laptop though, maybe i did not removed both waterways before rebuilding them.

There is a lot of log output, now. Which do you need for further investigation?

[Benedikt Straub (nordfriese)]

Please do try to obtain the replay file. I´ll be on holiday from next weekend on for 1½ weeks and will be unable to debug anything then…
Without a replay or a way to reproduce, I can´t investigate further. In the savegame, there already are two fleets where only one should exist; there´s no telling now when and why and how exactly the additional one was created. I suspect it´s an issue with the pathfinder; the new log output shows details of all its relevant steps.
If you can reproduce the bug again, please include all the log lines prefixed with "NOCOM"; and if you play widelands with --verbose, any lines containing "ferry_fleet", "ferry" or "waterway" might also be useful.

[kaputtnik (franku)]

OK, here is one replay showing that i played around with some waterways. The created waterways do also didn't get any ferry.

[kaputtnik (franku)]

Here is the replay containing creating the first waterway.

[Benedikt Straub (nordfriese)]

Thanks for the replays :)
My first guess was far off.
I assume you saved the game at around 30:00 and then reloaded? If I use a savegame created from the first replay before a waterway is built and then do all the things you did, I don´t get this bug.
I discovered that everything works well in the 1st replay, and a messed-up fleet system is created during loading the 2nd replay. So the bug is probably in the saving code…

[Benedikt Straub (nordfriese)]

The bug is probably fixed now :)
I´m not happy about the solution though, it feels like a hack and involves undoing a fix for an earlier bug. It didn´t reappear on a quick test, but I´m not sure if I didn´t just create some more hidden bugs…

[kaputtnik (franku)]

First of all: Sorry for my poor work on this. I am very busy with the website...

I will try to test your solution though, by starting a new game. Since you are on a holiday trip, i have time to do so ;)

Thanks for all your work :-)

[kaputtnik (franku)]

Another issue:

If you build waterways they are part of the economy, so they are considered for the routing of wares. If you didn't have a ferry yard yet (no ferry), wares are lying at the flags of waterways which might be needed for a building. This can be very confusing if a building needs a ware which is needed to build a ferry yard, but that ware is lying at a waterway waiting to be shipped. To solve this one has to remove the waterway where the ware is waiting for shipping.

So either the tutorial should explain to build waterways only if a ferry yard is already build, or the routing of wares should not consider waterways if no shipyard is built yet.

[kaputtnik (franku)]

Don't know if it is related to this branch, but i encountered a crash, see bug 1824586

[Benedikt Straub (nordfriese)]

Bug 1824586 should be fixed now (unable to test while sitting in the train).

Wares are also routed via ports before you have ships, if I´m not mistaken. Then I don´t think routing should take that into account. Also, you might have ferries without ferry yards (e.g. if a script gives them or you destroyed the yard).
Waterways could be considered inexistent until a ferry is assigned to it. Then separate road networks connected only by waterway keep being separate economies until one waterway gets a ferry. But in my opinion, there is no point building a waterway if you don´t have a ferry yard yet, so its your own fault if wares get stuck…

[kaputtnik (franku)]

> so its your own fault if wares get stuck…

I agree. Maybe its the same level of understanding like understanding problems related to ware jams.

[Klaus Halfmann (klaus-halfmann)]

I uploaded some Bug Video and a Savegamme to
https://www.magentacloud.de/share/tu4ayusx.k

please check

[TiborB (tiborb95)]

Hi, it seems to me that accidentally I created a mess, build material does not arrives to ferry yard, because it want to go through waterroad, that is not attended. Am I right?

[Benedikt Straub (nordfriese)]

Exactly, some wares are routed through the waterway, so they can´t be transported until it gets a ferry. We decided not to consider this situation a bug and rely on players to not build waterways before they have a ferry yard ;) (see comments #39-42)
I´ll also mention this in the extension to the seafaring tutorial which I´ll write when the branch is merged

[TiborB (tiborb95)]

Oh sorry. The discussion is quite long to read...

Also I noticed that Ferry yard produces ferries without limitation, so AI would need to watch unoccupied waterroads* and exceeding ferries as well..

* Even single unoccupied waterroad can lead to problems that can be hard to solve for AI

[GunChleoc (gunchleoc)]

When there's a waterway lacking a ferry, wares should be routed a different way. I have hardwood piled up towards the east from the headquarters.

[GunChleoc (gunchleoc)]

Here's a situation where a waterway should be possible but can't be built

[TiborB (tiborb95)]

"When there's a waterway lacking a ferry, wares should be routed a different way." - this is another difference to normal roads - normal roads are always staffed, so routing algorithm does not need to check if there is a carrier...

[GunChleoc (gunchleoc)]

When I have 2 economies only liked by a waterway, the metal workshop won't produce the necessary wares - I expect the request is generated by the wrong warehouse.

[Benedikt Straub (nordfriese)]

#47: See #44-45 and #39-42 (will have to explain this in the tutorial…)
#48: Where do you want your waterway to go? How much is the map´s length limit?
#50: Will investigate…

[GunChleoc (gunchleoc)]

> #48: Where do you want your waterway to go? How much is the map´s length limit?

Next to the Fisher's hut. waterway_max_length="4"

[Benedikt Straub (nordfriese)]

Waterways can´t be built along the coast, so the bug here is that an indicator is shown in an invalid spot…

[GunChleoc (gunchleoc)]

I'm wondering whether that restriction is more trouble than it's worth. It would of course allow a player to get another layer of roads along the coast as long as they don't block their fishers etc.

[GunChleoc (gunchleoc)]

Migrated to https://github.com/widelands/widelands/issues/2052