Notabilis has proposed merging
lp:~widelands-dev/widelands/bug-1782593-segfault-random-map into lp:widelands.
Commit message:
Fixing failed assert in random map generator and fixing bug in code for
selection of start position.
Requested reviews:
Widelands Developers (widelands-dev)
Related bu
LGTM :)
@bunnybot merge
--
https://code.launchpad.net/~widelands-dev/widelands/bug-1782593-segfault-random-map/+merge/350384
Your team Widelands Developers is requested to review the proposed merge of
lp:~widelands-dev/widelands/bug-1782593-segfault-random-map into lp:widelands.
___
So bug 1580892 (Random Map Generator doesn't always find viable player starting
positions) is also fixed with this branch?
--
https://code.launchpad.net/~widelands-dev/widelands/bug-1782593-segfault-random-map/+merge/350384
Your team Widelands Developers is requested to review the proposed merge
Thanks for the review and for looking up that bug.
It is not totally fixed. In current trunk it nearly never finds a valid
position, while with this branch it has a fair chance to assign valid start
positions. Its still random based and can fail but it fails much less frequent
that before (teste
Continuous integration builds have changed state:
Travis build 3698. State: passed. Details:
https://travis-ci.org/widelands/widelands/builds/406542858.
Appveyor build 3497. State: success. Details:
https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_bug_178259
The proposal to merge
lp:~widelands-dev/widelands/bug-1782593-segfault-random-map into lp:widelands
has been updated.
Status: Needs review => Merged
For more details, see:
https://code.launchpad.net/~widelands-dev/widelands/bug-1782593-segfault-random-map/+merge/350384
--
Your team Widelan
Continuous integration builds have changed state:
Travis build 3699. State: passed. Details:
https://travis-ci.org/widelands/widelands/builds/406553761.
Appveyor build 3498. State: success. Details:
https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_remove_sav
Benedikt Straub has proposed merging
lp:~widelands-dev/widelands/inputwarequeue_display into lp:widelands.
Commit message:
Missing wares (and workers) are indicated differently in InputQueueDisplays if
the ware is on the way to the building than if it's really missing
Requested reviews:
Widel
Good feature, I like it.
The structure of the code looks good, but there might be a bug in the
calculations. When testing I reduced the maximum amount of requested wares for
a building. It seems as if the number of darker shadow (the wares on their
way?) is always the number of wares I reduced
The bug was that request_->get_open_count() also seems to count wares that
could be brought to the building at once if suddenly needed. Fixed this now by
defining in the GUI that all wares beyond the player-defined limit are shown as
missing unless they´re present.
>From left to right in the qu
Continuous integration builds have changed state:
Travis build 3702. State: passed. Details:
https://travis-ci.org/widelands/widelands/builds/406665001.
Appveyor build 3501. State: success. Details:
https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_inputwareq
Thanks, it seems much more logical now. Mostly, that is, sometimes the "dark"
section changes its size based on the current max-amount (i.e., 2 cloth
requested -> 2 dark; 3 cloth requested -> only 1 dark). Might be correct inside
the code based on how requests are calculated, guess you can't do
12 matches
Mail list logo
