[Wesnoth-bugs] [bug #24501] Scrolling terrain palette with mousewheel scrolls map too

Update of bug #24501 (project wesnoth): Status:None => Fixed Assigned to:None => vultraz ___ Follow-up Comment #6: Fixed:

[Wesnoth-bugs] [bug #25065] New credits won't display if too many entries are present

Update of bug #25065 (project wesnoth): Status:None => Confirmed Assigned to:None => jyrkive ___ Reply to this item at:

[Wesnoth-bugs] [bug #24501] Scrolling terrain palette with mousewheel scrolls map too

Follow-up Comment #7, bug #24501 (project wesnoth): Yay, confirmed fixed. ___ Reply to this item at: ___ Message sent via/by Gna! http://gna.org/

[Wesnoth-bugs] [bug #25285] crash starting campaign

Follow-up Comment #4, bug #25285 (project wesnoth): > I can still reproduce a crash here if I resize the wesnoth window while the scenario is loading (== during the loading screen). So it only happens if you resize dring the loadingscreen? In that case it would be a result of

[Wesnoth-bugs] [bug #25548] 'use map settings' not greyed out in mp create

URL: Summary: 'use map settings' not greyed out in mp create Project: Battle for Wesnoth Submitted by: gfgtdf Submitted on: Di 28 Feb 2017 14:40:45 UTC Category: Bug Severity:

[Wesnoth-bugs] [bug #25547] Addon mnager closes when doubleckicking on the list

URL: Summary: Addon mnager closes when doubleckicking on the list Project: Battle for Wesnoth Submitted by: gfgtdf Submitted on: Di 28 Feb 2017 14:35:29 UTC Category: Bug

[Wesnoth-bugs] [bug #21930] mp modifications options tags appear in savefiles even when inactive

Update of bug #21930 (project wesnoth): Status:None => Fixed ___ Follow-up Comment #1: Doesn't seem to be an issue in 1.13.6+dev. Only active modifications appear in savefiles.

[Wesnoth-bugs] [bug #25285] crash starting campaign

Follow-up Comment #3, bug #25285 (project wesnoth): I can still reproduce a crash here if I resize the wesnoth window while the scenario is loading (== during the loading screen). ___ Reply to this item at:

[Wesnoth-bugs] [bug #25161] editor generates invalid map, crash while loading (expand map)

Follow-up Comment #3, bug #25161 (project wesnoth): I'm sorry for the delay. Looks good, please close. :) ___ Reply to this item at: ___ Message sent via/by

[Wesnoth-bugs] [bug #25393] heap use after free in MP map selection

Follow-up Comment #2, bug #25393 (project wesnoth): Well, this is fixed as of right now so it can be closed. Didn't spot any other issues around this but with {A,UB}SAN. ___ Reply to this item at:

[Wesnoth-bugs] [bug #25161] editor generates invalid map, crash while loading (expand map)

Update of bug #25161 (project wesnoth): Status: Ready For Test => Fixed ___ Reply to this item at: ___ Nachricht

[Wesnoth-bugs] [bug #25393] heap use after free in MP map selection

Update of bug #25393 (project wesnoth): Status:None => Fixed ___ Reply to this item at: ___ Nachricht

[Wesnoth-bugs] [bug #25549] poisoned units appear white instead of green

URL: Summary: poisoned units appear white instead of green Project: Battle for Wesnoth Submitted by: gfgtdf Submitted on: Di 28 Feb 2017 16:50:31 UTC Category: Bug Severity: 3

[Wesnoth-bugs] [bug #25549] poisoned units appear white instead of green

Follow-up Comment #2, bug #25549 (project wesnoth): I recall this as well play-testing Secrets of the Ancients - my Necrophage/Ghast was turning units white instead of green. I need to play more Wesnoth - it didn't register in my mind that that was incorrect.

[Wesnoth-bugs] [bug #25548] 'use map settings' not greyed out in mp create

Follow-up Comment #2, bug #25548 (project wesnoth): Im using a build from about a week ago ___ Reply to this item at: ___ Nachricht gesendet von/durch Gna!

[Wesnoth-bugs] [bug #25548] 'use map settings' not greyed out in mp create

Follow-up Comment #1, bug #25548 (project wesnoth): Cannot repro. I did fix an issue with the settings buttons a few days ago. Are you sure you're on latest master? ___ Reply to this item at:

[Wesnoth-bugs] [bug #25467] game map unresponsive

Follow-up Comment #3, bug #25467 (project wesnoth): I had a similar issue when i resized the window during the loadingscreen dialog. Are you didn't do a similar thing before? ___ Reply to this item at:

[Wesnoth-bugs] [bug #25549] poisoned units appear white instead of green

Follow-up Comment #1, bug #25549 (project wesnoth): Confirmed. I must have screwed up something in the color_t transition. :( ___ Reply to this item at: ___

[Wesnoth-bugs] [bug #25548] 'use map settings' not greyed out in mp create

Update of bug #25548 (project wesnoth): Status:None => Fixed Assigned to:None => vultraz ___ Reply to this item at:

[Wesnoth-bugs] [bug #25548] 'use map settings' not greyed out in mp create

Follow-up Comment #3, bug #25548 (project wesnoth): Ok it should be fixed in current master then. The problem was twofold: First, the GUI2 field API doesn't update the linked widget if it cannot find it, and I had the preshow call to update the settings button after a new tab had been selected.

[Wesnoth-bugs] [bug #21564] Failed to show a dialog, which doesn't fit on the screen.

Update of bug #21564 (project wesnoth): Severity: 3 - Normal => 4 - Important Priority: 5 - Normal => 6 ___ Follow-up Comment #5: I think the

[Wesnoth-bugs] [bug #25547] Addon mnager closes when doubleckicking on the list

Update of bug #25547 (project wesnoth): Status:None => Fixed Assigned to:None => vultraz Open/Closed:Open => Closed

[Wesnoth-bugs] [bug #25332] Texts including alphanumeric or symbol are not displayed in help when language is Japanese or Chinese.

Update of bug #25332 (project wesnoth): Status: In Progress => Fixed ___ Follow-up Comment #7: Fixed by merging pull request #937:

[Wesnoth-bugs] [bug #25547] Addon mnager closes when doubleckicking on the list

Follow-up Comment #5, bug #25547 (project wesnoth): I didn't mean to re-open it. I think what happened was that I had the bug already open, you replied, then I replied on the original state before you had already closed it. :/ 'All's well that ends well...'

[Wesnoth-bugs] [bug #25541] tutorial: hard crash as delfador summons training dummy for konrad.

Follow-up Comment #9, bug #25541 (project wesnoth): Looks like this was in the last few commits. Just retested against d8973041 and it seems okay now. ___ Reply to this item at:

[Wesnoth-bugs] [bug #25549] poisoned units appear white instead of green

Follow-up Comment #5, bug #25549 (project wesnoth): https://github.com/wesnoth/wesnoth/blob/1.13.6/src/units/drawer.cpp#L124 ___ Reply to this item at: ___

[Wesnoth-bugs] [bug #25549] poisoned units appear white instead of green

Follow-up Comment #4, bug #25549 (project wesnoth): somewhere in units/frame.cpp, I'd imagine. ___ Reply to this item at: ___ Message sent via/by Gna!

[Wesnoth-bugs] [bug #25547] Addon mnager closes when doubleckicking on the list

Update of bug #25547 (project wesnoth): Open/Closed:Open => Closed ___ Follow-up Comment #4: Since this isn't an issue in a released version, it can be closed immediately.

[Wesnoth-bugs] [bug #25541] tutorial: hard crash as delfador summons training dummy for konrad.

Update of bug #25541 (project wesnoth): Status: In Progress => Fixed ___ Follow-up Comment #8: This and several more related errors/crashes have been fixed by celmin. Still, more testing

[Wesnoth-bugs] [bug #25549] poisoned units appear white instead of green

Follow-up Comment #3, bug #25549 (project wesnoth): I scanned through for instances of STATE_POISONED... I can see lots of places in attack and unit and ai, etc, where this is used, but not really sure where the unit overlay that turns the unit green is supposed to happen.

[Wesnoth-bugs] [bug #25547] Addon mnager closes when doubleckicking on the list

Update of bug #25547 (project wesnoth): Open/Closed: Closed => Open ___ Follow-up Comment #2: Seems to be resolved in

[Wesnoth-bugs] [bug #25547] Addon mnager closes when doubleckicking on the list

Follow-up Comment #3, bug #25547 (project wesnoth): Ugh, not sure why I didn't see vultraz' post before. ___ Reply to this item at: ___ Message sent via/by Gna!

[Wesnoth-bugs] [bug #25549] poisoned units appear white instead of green

Follow-up Comment #6, bug #25549 (project wesnoth): Thanks. I stepped through from unit_drawer::redraw_unit() in drawer.cpp to unit_frame::merge_parameters() in frame.cpp. /** engine provide a blend color for poisoned units */ result.blend_with = current_val.blend_with ? current_val.blend_with

[Wesnoth-bugs] [bug #25549] poisoned units appear white instead of green

Follow-up Comment #7, bug #25549 (project wesnoth): Just as an experiment, I changed frame_parsed_parameters::parameters() (frame.cpp:561) so that blend_with is initialised to color_t(0, 0, 0) instead of just copying the uninitialised blend_with_ member. Poisoned units are rendered green again.

[Wesnoth-bugs] [bug #23037] force_lock_settings=yes in campaigns

Follow-up Comment #3, bug #23037 (project wesnoth): I'm not sure what the best way to deal with this would be. ___ Reply to this item at: ___ Message sent

[Wesnoth-bugs] [bug #25549] poisoned units appear white instead of green

Follow-up Comment #11, bug #25549 (project wesnoth): I'm not familiar with what the optional<> does, but that line 952 was what I was looking at before. It might do some sort of check, but result.blend_with uses the uninitialised current_val.blend_with (line above), which in turn is taken from

[Wesnoth-bugs] [bug #25549] poisoned units appear white instead of green

Follow-up Comment #13, bug #25549 (project wesnoth): Essentially, yeah. The old code used uint32_t's which could be default-initialized to 0. ___ Reply to this item at:

[Wesnoth-bugs] [bug #25549] poisoned units appear white instead of green

Follow-up Comment #9, bug #25549 (project wesnoth): i just found somethign possibly related: at https://github.com/wesnoth/wesnoth/blob/f2d730bd86d6b8b97d89d3f92176a44af6026dc4/src/units/frame.cpp#L952 uses result.blend_with but doesn't check that is initilized.

[Wesnoth-bugs] [bug #25549] poisoned units appear white instead of green

Follow-up Comment #12, bug #25549 (project wesnoth): http://www.boost.org/doc/libs/1_63_0/libs/optional/doc/html/index.html So are we using optional<> to avoid having a null color_t object? Is this why blend_with_ seems to be uninitialised by default? Just trying to get an understanding of how

[Wesnoth-bugs] [bug #25549] poisoned units appear white instead of green

Follow-up Comment #10, bug #25549 (project wesnoth): You're looking at an outdated diff. In master it is checked: https://github.com/wesnoth/wesnoth/blob/master/src/units/frame.cpp#L952 ___ Reply to this item at:

[Wesnoth-bugs] [bug #25549] poisoned units appear white instead of green

Follow-up Comment #8, bug #25549 (project wesnoth): > I see the frame_parameter() and frame_builder() constructors leave blend_with uninitialised, but I would have thought that they would take the default color_t() constructor. Note that blend_with is not a color_t but a optional

[Wesnoth-bugs] [bug #25549] poisoned units appear white instead of green

Follow-up Comment #15, bug #25549 (project wesnoth): How would that work? RGBA 0,0,0,0 is fully transparent black :/ ___ Reply to this item at: ___ Message sent

[Wesnoth-bugs] [bug #25550] Secrets of the Ancients: Broken Chocobone Lua Code

URL: Summary: Secrets of the Ancients: Broken Chocobone Lua Code Project: Battle for Wesnoth Submitted by: wedge009 Submitted on: Wed 01 Mar 2017 05:52:42 PM AEDT Category: Bug

[Wesnoth-bugs] [bug #25549] poisoned units appear white instead of green

Follow-up Comment #14, bug #25549 (project wesnoth): I see. So should we introduce zero initialisation to the constructors? ___ Reply to this item at: ___