Merge lp://qastaging/~widelands-dev/widelands/bug-1827033-shipping-algorithm into lp://qastaging/widelands

Proposed by Benedikt Straub
Status: Merged
Merged at revision: 9127
Proposed branch: lp://qastaging/~widelands-dev/widelands/bug-1827033-shipping-algorithm
Merge into: lp://qastaging/widelands
Diff against target: 68 lines (+18/-8)
2 files modified
src/economy/portdock.cc (+16/-7)
src/logic/map_objects/tribes/ship.cc (+2/-1)
To merge this branch: bzr merge lp://qastaging/~widelands-dev/widelands/bug-1827033-shipping-algorithm
Reviewer Review Type Date Requested Status
GunChleoc Approve
Review via email: mp+366959@code.qastaging.launchpad.net

Commit message

Fix an assert fail because of nullptr destinations in the shipping algorithm

Description of the change

I have a feeling that this only masks the real issue. Portdock code first removes items that don´t have a portdock as destination and implicitly re-adds them at once. This causes *nullptr to be passed as an argument, resulting in the assert fail.
This branch simply prevents this situation by skipping something that doesn´t work anyway, so it shouldn´t have undesired side-effects. Someone who knows (or wrote) that code should check why the unallowed elements are adressed to a portdock when they should not be and therefore re-add themselves...

To post a comment you must log in.
Revision history for this message
bunnybot (widelandsofficial) wrote :

Continuous integration builds have changed state:

Travis build 4896. State: passed. Details: https://travis-ci.org/widelands/widelands/builds/528437763.
Appveyor build 4677. State: success. Details: https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_bug_1827033_shipping_algorithm-4677.

Revision history for this message
kaputtnik (franku) wrote :

I am in favor to revert the changes that caused this failure... although the 'old' shipping algorithm isn't perfect.

Revision history for this message
Benedikt Straub (nordfriese) wrote :

Apart from this bug, which happens quite often, no unusual behaviour was observed in shipping so far. I would vote to merge this symptomatic fix, and if more problems are found, to revert or rewrite the algorithm.

Revision history for this message
kaputtnik (franku) wrote :

> no unusual behaviour was observed in shipping so far.

I think it is very unusual that a ship navigate to a port, unload all wares and immediately load the same wares again to navigate the wares to the destination port. In the end this means the time a ware is transported will grow with the number of ports.

Shouldn't the question be: Does the new shipping algorithm add any features?

But i agree that this bug should fixed very soon. Test games on seafaring maps makes no fun until this is fixed.

Revision history for this message
GunChleoc (gunchleoc) wrote :

I have added a tiny code style tweak. I'll let some AIs dish it out on this branch now.

Sorry for dragging my heels on this one.

review: Approve
Revision history for this message
GunChleoc (gunchleoc) wrote :

> I think it is very unusual that a ship navigate to a port, unload all wares and immediately load the same wares again to navigate the wares to the destination port. In the end this means the time a ware is transported will grow with the number of ports.

This should definitely be fixed too

> Shouldn't the question be: Does the new shipping algorithm add any features?

The goal was to make ship transportation more efficient overall

Revision history for this message
Benedikt Straub (nordfriese) wrote :

> I think it is very unusual that a ship navigate to a port, unload all wares and immediately load the same wares again to navigate the wares to the destination port.

Wasn´t aware of that one yet, but that has to be fixed of course.
I think this won´t be possible without rewriting most of the shipping algorithm due to the sometimes strange and potentially very buggy codeflow. I will try that out soon.
This branch should be considered a provisional fix to make seafaring games on debug builds possible again without a crash every two minutes, and hopefully I can provide a more stable algorithm (with a different approach) to replace it sometime soon.

Revision history for this message
kaputtnik (franku) wrote :

This behavior applies also for workers (soldiers), as mentioned in the bug report at #3 (4. paragraph) and comment #6 (replay).

Lets have this then and create another bug report?

Revision history for this message
GunChleoc (gunchleoc) wrote :

@bunnybot merge

Revision history for this message
bunnybot (widelandsofficial) wrote :

Continuous integration builds have changed state:

Travis build 5062. State: passed. Details: https://travis-ci.org/widelands/widelands/builds/537402325.
Appveyor build 4842. State: failed. Details: https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_bug_1827033_shipping_algorithm-4842.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches

to status/vote changes: