[Wesnoth-bugs] [bug #25195] MP: faction leader menu auto-closes after scrolling

Update of bug #25195 (project wesnoth): Status:None => Confirmed Release: git => 1.13.5+dev Operating System: linux => All Summary:

[Wesnoth-bugs] [bug #24022] Crash on Quit Scenario With Planned Recruits Present

Update of bug #24022 (project wesnoth): Status:None => Fixed Assigned to:None => wedge009 Release: master => 1.13.1+dev

[Wesnoth-bugs] [bug #25193] heap use after free when quitting game after recruiting and moving same unit in planning mode

Update of bug #25193 (project wesnoth): Status:None => Duplicate Assigned to:None => wedge009 Open/Closed:Open => Closed

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #1, bug #25186 (project wesnoth): After some more investigation, I discovered I can reproduce the issue with just this code: [while] {EQ var $null} [do] [message] speaker="narrator" [option] label="label" [/option]

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #3, bug #25186 (project wesnoth): I haven't tried putting the code in every single mainline scenario, but I tried placing it in Aethermaw's existing start event, and the lag occurred with no mods enabled. ___ Reply to

[Wesnoth-bugs] [bug #25192] reference binding to nullpointer when clicking unit recruited in planning mode

Update of bug #25192 (project wesnoth): Status:None => Ready For Test ___ Follow-up Comment #2: https://github.com/wesnoth/wesnoth/commit/30b8a2c0369c4f0ffb1fc19a198c319dd3002053

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #2, bug #25186 (project wesnoth): Just to be sure, putting this code in any mainline scenario reproduces this issue without any additional mods? ___ Reply to this item at:

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #4, bug #25186 (project wesnoth): Cold you please test whether it still happens if you rmeove the wesnoth.deselect_hex() here: https://github.com/wesnoth/wesnoth/blob/1.13.5/data/lua/wml/message.lua#L347 ? ___ Reply to

[Wesnoth-bugs] [bug #25083] leaks in AI vs AI match

Follow-up Comment #1, bug #25083 (project wesnoth): These are all unit attacks being allocated, but in all cases they're stored in a boost::intrusive_ptr, so I don't see how they're being leaked. My guess would be that either there's something wrong with the refcount or the messages are spurious.

[Wesnoth-bugs] [bug #25077] memleak in wesnoth help

Follow-up Comment #1, bug #25077 (project wesnoth): This appears to be the same as #25083. ___ Reply to this item at: ___ Message sent via/by Gna!

[Wesnoth-bugs] [bug #25083] leaks in AI vs AI match

Follow-up Comment #2, bug #25083 (project wesnoth): Ok looking at these lines, it eems like intrusive_ptr_release is just not frreing the object in case that teh refcount is 0. ___ Reply to this item at:

[Wesnoth-bugs] [bug #25083] leaks in AI vs AI match

Follow-up Comment #3, bug #25083 (project wesnoth): freeing*, the*, seems* ___ Reply to this item at: ___ Nachricht gesendet von/durch Gna! http://gna.org/

[Wesnoth-bugs] [bug #20861] Modifications

Update of bug #20861 (project wesnoth): Status: Confirmed => Fixed ___ Follow-up Comment #5: Assuming to be fixed. ___ Reply to

[Wesnoth-bugs] [bug #25192] reference binding to nullpointer when clicking unit recruited in planning mode

Follow-up Comment #3, bug #25192 (project wesnoth): The game crashes now when hovering a unit. new log attached (file #29049) ___ Additional Item Attachment: File name: hovercrash.log Size:2 KB

[Wesnoth-bugs] [bug #25192] reference binding to nullpointer when clicking unit recruited in planning mode

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

[Wesnoth-bugs] [bug #25192] reference binding to nullpointer when clicking unit recruited in planning mode

Follow-up Comment #4, bug #25192 (project wesnoth): Was fixed via https://github.com/wesnoth/wesnoth/commit/4b9ec1bce1b13f08d58a20394a3d10b954e59d0e (I can no longer reproduce the crash or the nullptr) Thanks! ___ Reply to this item at:

[Wesnoth-bugs] [bug #25186] [message] lag

Follow-up Comment #5, bug #25186 (project wesnoth): No change. It is specifically related to the "narrator" value though; specifying the speaker as "unit" does not result in lag, for example. ___ Reply to this item at: