Latest Posts

Topic: Ferries

Nordfriese
Avatar
Topic Opener
Joined: 2017-01-17, 18:07
Posts: 1929
OS: Debian Testing
Version: Latest master
Ranking
One Elder of Players
Location: 0x55555d3a34c0
Posted at: 2018-08-03, 17:17

einstein13 wrote:

@Nordfriese
Does your screenshot contain a join between two separate economies?

No, there´s also a road connection out of sight. But it´s much longer, that´s why wares are sent through the ferry (the warehouse is in the north). The builder and the carriers for the southern roads used the land route though, as they should.

Going back to the topic, I haven't thought that economies in Widelands will cause so many problems. I thought that working ports and ships are enough to introduce ware transportation via ferries. You can just make two separate (but very similar) functions to path finding: one for ware and second for worker. Ware path finding will include ferries and waterways, but worker path finding will not. That would be simple, but will include going through the whole code.

The pathfinder already works like this: Waterways are treated exactly like roads when routing wares, and excluded when routing workers. This was a fairly trivial change actually.

But economies are mainly responsible for handling supplies and requests. Whenever a building needs a Ware or Worker, it registers a Request at its Economy. The Economy then looks for a Supply and sends it to the building that issued the Request. The problematic assumption here is that all Supplies can reach all Flags belonging to their Economy. I don´t know how it is implemented – perhaps it would be possible to exclude WorkerSupplies from consideration if they are not reachable from the destination; but this is an essential and very stable part of the code, so I´m reluctant to change it…


Top Quote
einstein13
Avatar
Joined: 2013-07-29, 00:01
Posts: 1118
Ranking
One Elder of Players
Location: Poland
Posted at: 2018-08-03, 22:13

Ok... so let me test it. Where I can find Windows binaries?

My point is that I can try to make separate economy by splitting current one. Also I would like to see what happen with all ware and worker requests. Maybe changes aren't so drastic as you are talking? Maybe there is a smooth solution? Can you send a link to the code reference where you have found those problems?


einstein13
calculations & maps packages: http://wuatek.no-ip.org/~rak/widelands/
backup website files: http://kartezjusz.ddns.net/upload/widelands/

Top Quote
hessenfarmer
Avatar
Joined: 2014-12-11, 23:16
Posts: 2646
Ranking
One Elder of Players
Location: Bavaria
Posted at: 2018-08-04, 01:24

https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_ferry-3552


Top Quote
Ex-Member
Avatar
Joined: 2014-09-12, 10:53
Posts: 184
Ranking
Widelands-Forum-Junkie
Posted at: 2018-08-04, 10:22

It may be advantageous at some time to revisit the ware request/allocation code anyway, if this also make ferries easier then it is win/win.

A problem situation. You build a port by an expedition, the port needs some sort of defence quickly and often there are trees and rocks to clear. You start building two or three buildings and goods are allocated from anywhere in the economy. Quite often the military building is waiting for the last log or stone which is travelling around the map while the warehouse next to the build site is filling with logs and stone from the buildings finished first. It would be better if the allocation of wares was determined by the distance and if a new producer/supply comes online the the allocations are recalculated.


Top Quote
teppo

Joined: 2012-01-30, 09:42
Posts: 423
Ranking
Tribe Member
Posted at: 2018-08-04, 10:32

Tinker wrote:

Quite often the military building is waiting for the last log or stone which is travelling around the map while the warehouse next to the build site is filling with logs and stone from the buildings finished first. It would be better if the allocation of wares was determined by the distance and if a new producer/supply comes online the the allocations are recalculated.

Annoying indeed. On the other hand, routing of wares is a significant contributor to Widelands CPU load already. If wares in transit would be continuously rerouted, this could get worse.


Top Quote
ypopezios
Avatar
Joined: 2018-04-20, 00:22
Posts: 220
Ranking
Widelands-Forum-Junkie
Posted at: 2018-08-05, 08:42

We should design ferries as a complete feature and reach there in steps.

Tribe-specific limits seem pointless to me, cause this is really a map feature. I would prefer maps to have options, like it's currently done with fog-of-war. In ferries' case, that could be an option among no-ferries (could be the default for old maps), short-distance-only ferries (maybe a value of 6), and unlimited-distance ferries (like land-roads). No more bothering about breaking existing maps. And later we can introduce shallow waters, to let map-designers fine-tune their maps.

Likewise, ferries should finally be able to transfer workers (I believe that's inevitable). And it's not as hard to be coded as it initially seems (but for sure it will have to wait for B21). The needed code should not touch economies and it has nothing to do with how ships do it (e.g. no special building). Ships should get improved independently of ferries and there is no need for a third type of small boats. Have a look at my recent effort of ship-scheduling: 32-bit 64-bit

Tinker wrote:

It may be advantageous at some time to revisit the ware request/allocation code anyway, if this also make ferries easier then it is win/win.

and

teppo wrote:

On the other hand, routing of wares is a significant contributor to Widelands CPU load already. If wares in transit would be continuously rerouted, this could get worse.

I have planned to revisit the ware request/allocation code (that's a big win for many reasons), but this has to happen in smaller steps. Continuous rerouting won't happen. But big (port-level / warehouse-level) rerouting is in the plans. And small (flag-level) rerouting is already implemented for the basic case. If you want to help to that direction, you can test current step here. But let's limit this thread on ferries.

Edited: 2018-08-11, 22:36

Top Quote
einstein13
Avatar
Joined: 2013-07-29, 00:01
Posts: 1118
Ranking
One Elder of Players
Location: Poland
Posted at: 2018-08-05, 14:21

I have tried to test the appveyor build. I couldn't build any ferry (building was consuming wood and nothing happen). Also I have found that if you destroy a part of the road, new economy has a problem with connecting with old one (rebuilding destroyed road).

Rebuilding roads is a common situation. There will be many situations where you build a part of the roads, build some waterways, destroy roads and rebuild them again. With current code, waterways will not work any more.

Edited: 2018-08-05, 14:23

einstein13
calculations & maps packages: http://wuatek.no-ip.org/~rak/widelands/
backup website files: http://kartezjusz.ddns.net/upload/widelands/

Top Quote
WorldSavior
Avatar
Joined: 2016-10-15, 04:10
Posts: 2091
OS: Linux
Version: Recent tournament version
Ranking
One Elder of Players
Location: Germany
Posted at: 2018-08-05, 18:37

ypopezios wrote:

We should design ferries as a complete feature and reach there in steps.

Tribe-specific limits seem pointless to me, cause this is really a map feature. I would prefer maps to have options, like it's currently done with fog-of-war. In ferries' case, that could be an option among no-ferries (could be the default for old maps), short-distance-only ferries (maybe a value of 6), and unlimited-distance ferries (like land-roads). No more bothering about breaking existing maps.

Very good idea


Wanted to save the world, then I got widetracked

Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 15:56
Posts: 3324
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2018-08-06, 11:53

+1 for the map-specific limits face-smile.png


Busy indexing nil values

Top Quote
Nordfriese
Avatar
Topic Opener
Joined: 2017-01-17, 18:07
Posts: 1929
OS: Debian Testing
Version: Latest master
Ranking
One Elder of Players
Location: 0x55555d3a34c0
Posted at: 2018-08-12, 08:30

Fixed an annoying crash and a couple of other bugs now. The branch is testable again. Ferries can now be built on any shore, road rendering works again, and the ferry is visible when shipping wares.

Tribe-specific limits seem pointless to me, cause this is really a map feature. I would prefer maps to have options, like it's currently done with fog-of-war. In ferries' case, that could be an option among no-ferries (could be the default for old maps), short-distance-only ferries (maybe a value of 6), and unlimited-distance ferries (like land-roads). No more bothering about breaking existing maps.

Good idea, but I´m afraid this exceeds my programming abilities, as it will require changes to the editor GUI and the map_io. If someone would prepare a branch for me that takes care of that, I´d implement it like this…
I don´t like the idea of hardcoding the short-distance limit, we could stick with the tribe-specific value in that case. Or we could allow the map designer to set the limit for every map individually.

I have thought more about waterways connecting separate economies. The request-handling code could probably be adjusted easier than I thought, but this will necessarily break the economy´s handling of worker demands anyway: Assume you have a warehouse with shovels in the southern half and an unoccupied foresters house in the northern part of the economy. The parts are connected only by waterway. A shovel will be turned into a forester to fulfill the demand, but the forester can´r reach the site, so another shovel is used up for another forester and so on. This is problematic in many cases also because of this bug.


Top Quote