[Wesnoth-bugs] [bug #24456] Wrong damage numbers in unit's description.

Update of bug #24456 (project wesnoth): Status: Need Info => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #18: Guess I should

[Wesnoth-bugs] [bug #24456] Wrong damage numbers in unit's description.

Follow-up Comment #17, bug #24456 (project wesnoth): When I made the commit *four years ago*, I knew how it behaved. After spending over two years without looking at Wesnoth code, I've forgotten details. So, yes, it was a guess based upon a quick look at the commit. If that's not good enough for

[Wesnoth-bugs] [bug #24456] Wrong damage numbers in unit's description.

Follow-up Comment #12, bug #24456 (project wesnoth): That "mostlikeley" phrasing makes me think you are guessing about what happens. I can do that to: the change to the c++ code most likely affects only those specials without filters. Guessing games are not productive. It is not hard to play

[Wesnoth-bugs] [bug #24456] Wrong damage numbers in unit's description.

Follow-up Comment #10, bug #24456 (project wesnoth): Charge doesn't have a filter. ___ Reply to this item at: ___ Message sent via/by Gna! http://gna.org/

[Wesnoth-bugs] [bug #25041] Unit types always exist in Lua (segmentation fault)

Follow-up Comment #1, bug #25041 (project wesnoth): The commit on GitHub ___ Reply to this item at:

[Wesnoth-bugs] [bug #25041] Unit types always exist in Lua (segmentation fault)

URL: Summary: Unit types always exist in Lua (segmentation fault) Project: Battle for Wesnoth Submitted by: jamit Submitted on: Mon 05 Sep 2016 01:22:36 PM EDT Category: Bug

[Wesnoth-bugs] [bug #24456] Wrong damage numbers in unit's description.

Update of bug #24456 (project wesnoth): Status:None => Need Info Assigned to:None => jamit ___ Follow-up Comment #7: I believe this is

[Wesnoth-bugs] [bug #24499] editor: memleaks

Update of bug #24499 (project wesnoth): Status:None => Fixed Assigned to:None => jamit ___ Follow-up Comment #1: Fixed in

[Wesnoth-bugs] [bug #23909] SDL2 Colour Cursors broken on ATI/AMD GPUs under Linux

Follow-up Comment #8, bug #23909 (project wesnoth): Let me know if this is still a problem for anyone after my commit. I can't test all hardware, but in theory this should work around the problem for everyone. And it did fix the problem for me (using AMD and Linux). It is still technically an

[Wesnoth-bugs] [bug #22466] Heir to the Throne - Home of the North Elves - dialogue in wrong place

Follow-up Comment #2, bug #22466 (project wesnoth): That is how I intended it. My thinking was that since sighted events fire with recruitment, recalling, and advancement, you could use sighted events without fog/shroud as one way to detect when a unit of a certain type appears on the map. (In a

[Wesnoth-bugs] [bug #21082] Replay crash (exits wesnoth) in Legend of Wesmere, scenario 3

Update of bug #21082 (project wesnoth): Status:None = Invalid Open/Closed:Open = Closed ___ Reply to this item at:

[Wesnoth-bugs] [bug #21257] Lagging in Unit Movement

Follow-up Comment #16, bug #21257 (project wesnoth): Looks more like a band-aid than a solution. ___ Reply to this item at: http://gna.org/bugs/?21257 ___ Message sent via/by Gna!

[Wesnoth-bugs] [bug #21740] Side leader name is not localized in the tooltip of the team side flag on the status panel

Update of bug #21740 (project wesnoth): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #1: Duplicate of bug

[Wesnoth-bugs] [bug #19660] Untranslateable sides in campaigns

Update of bug #19660 (project wesnoth): Category: Feature Request = Bug ___ Follow-up Comment #2: Marked bug #21740 as a duplicate of this.

[Wesnoth-bugs] [bug #21258] Paladin portrait in infobox has wrong width

Update of bug #21258 (project wesnoth): Status:None = Fixed ___ Follow-up Comment #1: I do not know when/how this was fixed, but I have confirmed the problem in 1.11.6, and it no

[Wesnoth-bugs] [bug #21732] Editor starting position labels disappear until changed

Update of bug #21732 (project wesnoth): Status:None = Fixed Assigned to: fendrin = jamit Open/Closed:Open = Closed

[Wesnoth-bugs] [bug #21486] Team label clears a non-team label

Update of bug #21486 (project wesnoth): Status:None = Fixed ___ Reply to this item at: http://gna.org/bugs/?21486 ___ Message sent

[Wesnoth-bugs] [bug #21323] PersistenceWML crash

Update of bug #21323 (project wesnoth): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?21323 ___ Message sent

[Wesnoth-bugs] [bug #21722] event blocks with multiple names never fire

Update of bug #21722 (project wesnoth): Severity: 3 - Normal = 5 - Blocker Priority: 5 - Normal = 6 Status:None = In Progress Assigned to:

[Wesnoth-bugs] [bug #21577] Trait having percenage increase in damage displays incorrectly

Update of bug #21577 (project wesnoth): Status:None = Fixed Assigned to:None = jamit ___ Follow-up Comment #2: Fixed in

[Wesnoth-bugs] [bug #21722] event blocks with multiple names never fire

Update of bug #21722 (project wesnoth): Status: In Progress = Fixed ___ Follow-up Comment #1: Oops. Somehow the part of my modifications slipped out. Fixed in 7cb0f5b92866

[Wesnoth-bugs] [bug #21450] Units can be moved in linger mode

Update of bug #21450 (project wesnoth): Status: Confirmed = Fixed Assigned to: fendrin = jamit ___ Follow-up Comment #4: Fixed in

[Wesnoth-bugs] [bug #21178] Desert to water transitions broken in 1.10

Update of bug #21178 (project wesnoth): Status:None = Invalid Open/Closed:Open = Closed ___ Follow-up Comment #2: Changing the

[Wesnoth-bugs] [bug #21303] read-only variable is not assignable

Update of bug #21303 (project wesnoth): Status:None = Fixed Assigned to:None = jamit ___ Follow-up Comment #1: Even though there is

[Wesnoth-bugs] [bug #21434] Labels under shroud not displaying properly

Update of bug #21434 (project wesnoth): Status:None = Fixed Assigned to:None = jamit ___ Follow-up Comment #1: Fixed in

[Wesnoth-bugs] [bug #21310] Minimap buttons misplaced

Follow-up Comment #1, bug #21310 (project wesnoth): Is this still a problem with the latest release? There has been some work done on the minimap since 7e35715. (I cannot check myslef because when I reverted to 7e35715, I did not see this problem. It might have to do with your screen/window

[Wesnoth-bugs] [bug #3856] hide map at start of turn, to preserve fog/shroud in hotseat games

Update of bug #3856 (project wesnoth): Assigned to:None = jamit ___ Reply to this item at: http://gna.org/bugs/?3856 ___ Message sent

[Wesnoth-bugs] [bug #21310] Minimap buttons misplaced

Update of bug #21310 (project wesnoth): Status:None = Fixed Open/Closed:Open = Closed ___ Reply to this item at:

[Wesnoth-bugs] [bug #21394] show AI moves checkbox has no effect

Update of bug #21394 (project wesnoth): Status:None = Need Info ___ Follow-up Comment #1: Where is the show AI moves checkbox? I know of a Skip AI moves checkbox in the general

[Wesnoth-bugs] [bug #21372] Pressing 't' to continue moving after sighting unit no longer works

Follow-up Comment #2, bug #21372 (project wesnoth): This can be traced to 7e46df919167c6906d7a782b8f7710cdee5a, when mouse_handler::select_hex() was changed so that selected_hex_ = hex; became if (selected_hex_ == hex) selected_hex_ = map_location::null_location;

[Wesnoth-bugs] [bug #21661] fog is not refreshed for allied sides

Update of bug #21661 (project wesnoth): Status:None = Wont Fix Open/Closed:Open = Closed ___ Follow-up Comment #1: Fog was fixed in the

[Wesnoth-bugs] [bug #21647] Elipses randomly missing

Update of bug #21647 (project wesnoth): Status:None = Need Info ___ Follow-up Comment #4: I've tried reproducing the exact combination of unit, facing, and terrain that I see in the

[Wesnoth-bugs] [bug #21643] [lift_fog] can lift fog on a single hex, but it looks wrong

Update of bug #21643 (project wesnoth): Status:None = Fixed Assigned to:None = jamit ___ Follow-up Comment #2: Pushed a fix

[Wesnoth-bugs] [bug #21566] Right Click panel wrong position when unit moves.

Update of bug #21566 (project wesnoth): Status:None = Works For Me ___ Follow-up Comment #1: I was unable to reproduce the bug. The pop-up menu appeared by the mouse, not by the unit the

[Wesnoth-bugs] [bug #21643] [lift_fog] can lift fog on a single hex, but it looks wrong

Follow-up Comment #1, bug #21643 (project wesnoth): Oh, right. I forgot about this. The problem is partly in the code and partly in that Wesnoth does not have an image for a clear hex surrounded by fog. I had put off fixing (or is it just improving?) this earlier because that image was missing.

[Wesnoth-bugs] [bug #21466] Selecting enemy units doesn't make sense

Follow-up Comment #2, bug #21466 (project wesnoth): There is (at least) one reason I know of to select an enemy unit -- to get its information in the sidebar. OK, its information is displayed if you hover your mouse over it, but in that case the information is easily lost before you get a chance

[Wesnoth-bugs] [bug #21503] Does not launch in maximized window

Follow-up Comment #1, bug #21503 (project wesnoth): A more accurate description, as far as I can tell: The game ignores Windows' Run: setting, which has the options Normal window, Minimized, and Maximized. This setting can be found (in Windows XP) by right-clicking the shortcut and selecting

[Wesnoth-bugs] [bug #21398] FormulaAI: wrong subtraction

Update of bug #21398 (project wesnoth): Assigned to:None = jamit Summary: FormulaAI: wrong substraction = FormulaAI: wrong subtraction ___ Follow-up Comment #1: There is

[Wesnoth-bugs] [bug #21398] FormulaAI: wrong substraction

Update of bug #21398 (project wesnoth): Severity: 3 - Normal = 2 - Minor Status:None = Fixed ___ Reply to this item at:

[Wesnoth-bugs] [bug #21257] Lagging in Unit Movement

Update of bug #21257 (project wesnoth): Status: Need Info = Confirmed ___ Follow-up Comment #11: The video shows animation problems during the AI's turn with the option to skip AI moves

[Wesnoth-bugs] [bug #21214] MP Statistics wrongly lumps together all sides' recruits, kills, and losses

Follow-up Comment #6, bug #21214 (project wesnoth): Well, yeah. The status is none. If it was fixed, the status would be fixed. If you want it fixed faster, you are welcome to submit a patch. ___ Reply to this item at:

[Wesnoth-bugs] [bug #21343] Nested #define's

Update of bug #21343 (project wesnoth): Category: Bug = Feature Request Severity: 3 - Normal = 1 - Wish Priority: 5 - Normal = 3 - Low

[Wesnoth-bugs] [bug #13256] Assertion failure in src/actions.cpp, happened when moved (12, 8)- (10, 10)

Update of bug #13256 (project wesnoth): Severity: 4 - Important = 3 - Normal Status: Fixed = Postponed Assigned to:crab = jamit Open/Closed:

[Wesnoth-bugs] [bug #21331] Walking corpses are unknown units

Update of bug #21331 (project wesnoth): Open/Closed:Open = Closed ___ Follow-up Comment #5: I probably should have checked standard units instead of just reporting on a campaign-specific

[Wesnoth-bugs] [bug #21343] Nested #define's

Follow-up Comment #1, bug #21343 (project wesnoth): Just observing: if we were to take your example code, and apply the rule inside a #define, lines beginning by #define are comments, then stripping out that comment line would leave #define F Y Z {H Y A B} #enddef {K G {Z}} #undef G #enddef

[Wesnoth-bugs] [bug #21331] Walking corpses are unknown units

Update of bug #21331 (project wesnoth): Assigned to:None = fendrin ___ Follow-up Comment #2: Is this a duplicate of bug #21280? ___

[Wesnoth-bugs] [bug #21323] PersistenceWML crash

Update of bug #21323 (project wesnoth): Status:None = Duplicate ___ Follow-up Comment #1: Duplicate of bug #21093. ___ Reply to

[Wesnoth-bugs] [bug #21280] Help says Kaleh is unknown

URL: http://gna.org/bugs/?21280 Summary: Help says Kaleh is unknown Project: Battle for Wesnoth Submitted by: jamit Submitted on: Sun 17 Nov 2013 12:00:21 PM EST Category: Bug Severity: 3 - Normal

[Wesnoth-bugs] [bug #21281] Pango warning spam for UtBS

URL: http://gna.org/bugs/?21281 Summary: Pango warning spam for UtBS Project: Battle for Wesnoth Submitted by: jamit Submitted on: Sun 17 Nov 2013 12:16:38 PM EST Category: Bug Severity: 3 - Normal

[Wesnoth-bugs] [bug #21281] Pango warning spam for mousing over terrain

Update of bug #21281 (project wesnoth): Assigned to:None = fendrin Summary: Pango warning spam for UtBS = Pango warning spam for mousing over terrain ___ Follow-up Comment

[Wesnoth-bugs] [bug #21031] Weird event handling with multiple events, each firing events

Update of bug #21031 (project wesnoth): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?21031 ___ Message sent

[Wesnoth-bugs] [bug #18713] Creating a WML event handler inside another and firing it immediately afterwards does not work

Update of bug #18713 (project wesnoth): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?18713 ___ Message sent

[Wesnoth-bugs] [bug #21257] Lagging in Unit Movement

Follow-up Comment #5, bug #21257 (project wesnoth): What speed? I tried 0.5, 2, and 16, and all looked fine. ___ Reply to this item at: http://gna.org/bugs/?21257 ___ Message sent via/by

[Wesnoth-bugs] [bug #21257] Lagging in Unit Movement

Follow-up Comment #3, bug #21257 (project wesnoth): Still does not reproduce for me. (So I am still relying on clear, detailed reports of symptoms from others.) But I guess we have ruled out an OS-specific issue, since it's now been reported with Mac and Windows.

[Wesnoth-bugs] [bug #21257] Lagging in Unit Movement

Update of bug #21257 (project wesnoth): Status:None = Need Info Assigned to:None = jamit ___ Follow-up Comment #1: System specs? Newish

[Wesnoth-bugs] [bug #21248] wrong attack icon for Moremirmu

Follow-up Comment #1, bug #21248 (project wesnoth): Or d) change holy sword to holy staff. :) ___ Reply to this item at: http://gna.org/bugs/?21248 ___ Message sent via/by Gna!

[Wesnoth-bugs] [bug #21252] Mandatory WML child missing yet untested for. Please report. error

Update of bug #21252 (project wesnoth): Status:None = Need Info Assigned to:None = lipk ___ Follow-up Comment #1: To make this a more

[Wesnoth-bugs] [bug #21252] Mandatory WML child missing yet untested for. Please report. error

Update of bug #21252 (project wesnoth): Status: Need Info = Confirmed ___ Reply to this item at: http://gna.org/bugs/?21252 ___ Message sent

[Wesnoth-bugs] [bug #21214] MP Statistics wrongly lumps together all sides' recruits, kills, and losses

Follow-up Comment #1, bug #21214 (project wesnoth): Is it working in 1.10? ___ Reply to this item at: http://gna.org/bugs/?21214 ___ Message sent via/by Gna! http://gna.org/

[Wesnoth-bugs] [bug #18713] Creating a WML event handler inside another and firing it immediately afterwards does not work

Update of bug #18713 (project wesnoth): Status:None = Fixed ___ Follow-up Comment #4: Fixed: http://git.io/9Q8TCg ___ Reply

[Wesnoth-bugs] [bug #21198] Wesnoth loads data/core/unit and such WML twice for multiplayer

Follow-up Comment #4, bug #21198 (project wesnoth): There may be some merit to the idea that the game might be able to skip the initial data load if it is going to skip the main menu. At least, it makes sense at a high level; I don't know if there are technical details that would complicate

[Wesnoth-bugs] [bug #21198] Wesnoth loads data/core/unit and such WML twice for multiplayer

Follow-up Comment #1, bug #21198 (project wesnoth): Have you verified that the same information is in the file from loading multiplayer? If so, that is probably a bug. There should be differences in the Legend of Wesmere campaign, and in all (or at least most) of the scenarios where you can issue

[Wesnoth-bugs] [bug #21127] problems with wml_menu_item class

Update of bug #21127 (project wesnoth): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #4: Should be fixed with

[Wesnoth-bugs] [bug #21127] problems with wml_menu_item class

Follow-up Comment #3, bug #21127 (project wesnoth): I have a theory. If you want to test the theory before I get a chance to, change line 422 of handlers.cpp from handle_event_commands(event_info, vconfig(cfg_)); to handle_event_commands(event_info, vconfig(cfg_, true));

[Wesnoth-bugs] [bug #21127] problems with wml_menu_item class

Follow-up Comment #1, bug #21127 (project wesnoth): The references shouldn't make a difference if the compiler is doing any optimizations (vconfig::child() returns an object, not a reference). At the same time, it's an easy enough change to work in. The crash will take some looking into. I don't

[Wesnoth-bugs] [bug #21114] Crash when starting Wesnoth

Update of bug #21114 (project wesnoth): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #2: Duplicate of bug

[Wesnoth-bugs] [bug #21082] Replay crash (exits wesnoth) in Legend of Wesmere, scenario 3

Follow-up Comment #2, bug #21082 (project wesnoth): The crash in the original submission occurred because the replay said to recruit a unit in a space that was already occupied. I have not yet looked into why that space was occupied, but it would not be surprising for it to be a consequence of

[Wesnoth-bugs] [bug #21093] Bank teller crashes next load of test scenario

URL: http://gna.org/bugs/?21093 Summary: Bank teller crashes next load of test scenario Project: Battle for Wesnoth Submitted by: jamit Submitted on: Mon 02 Sep 2013 03:55:50 PM EDT Category: Bug Severity:

[Wesnoth-bugs] [bug #21093] Bank teller crashes next load of test scenario

Follow-up Comment #1, bug #21093 (project wesnoth): Forgot to mention: The Bank Teller hex is at 10,6. ___ Reply to this item at: http://gna.org/bugs/?21093 ___ Message sent via/by Gna!

[Wesnoth-bugs] [bug #21031] Weird event handling with multiple events, each firing events

URL: http://gna.org/bugs/?21031 Summary: Weird event handling with multiple events, each firing events Project: Battle for Wesnoth Submitted by: jamit Submitted on: Sat 17 Aug 2013 05:00:30 PM EDT Category: Bug

[Wesnoth-bugs] [bug #21031] Weird event handling with multiple events, each firing events

Update of bug #21031 (project wesnoth): Status: In Progress = Fixed Release: 1.11.5 = 1.11.6 ___ Follow-up Comment #1: Fixed in

[Wesnoth-bugs] [bug #20933] [base_unit] doesn't work for females

Update of bug #20933 (project wesnoth): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20933 ___ Message sent

[Wesnoth-bugs] [bug #20852] Mandatory WML child missing yet untested for. Please report.

Update of bug #20852 (project wesnoth): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20852 ___ Message sent

[Wesnoth-bugs] [bug #20742] Segfault before main menu

Update of bug #20742 (project wesnoth): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20742 ___ Message sent

[Wesnoth-bugs] [bug #21020] Segmentation fault

Update of bug #21020 (project wesnoth): Priority: 5 - Normal = 7 - High Status:None = Fixed Open/Closed:Open = Closed

[Wesnoth-bugs] [bug #20779] Irrational segmentation fault when returning from fire_event

Update of bug #20779 (project wesnoth): Status:None = Need Info Assigned to:None = jamit ___ Follow-up Comment #3: The attached save

[Wesnoth-bugs] [bug #20764] Starting gold in MP campaign is 2*mininum gold

Update of bug #20764 (project wesnoth): Status:None = Need Info ___ Reply to this item at: http://gna.org/bugs/?20764 ___ Message sent

[Wesnoth-bugs] [bug #20615] RFE: Request to rename cutter and exploder

Update of bug #20615 (project wesnoth): Category: Bug = Feature Request Priority: 5 - Normal = 3 - Low ___ Reply to this item at:

[Wesnoth-bugs] [bug #20562] A few keys in [side] stopped working

Update of bug #20562 (project wesnoth): Item Group: None of the others = Multiplayer Lobby ___ Reply to this item at: http://gna.org/bugs/?20562 ___ Message sent

[Wesnoth-bugs] [bug #18713] Creating a WML event handler inside another and firing it immediately afterwards does not work

Update of bug #18713 (project wesnoth): Assigned to:None = jamit ___ Reply to this item at: http://gna.org/bugs/?18713 ___ Message sent

[Wesnoth-bugs] [bug #20659] error message when mother unit, child unit and _initial.cfg in same folder

Update of bug #20659 (project wesnoth): Status:None = Invalid Open/Closed:Open = Closed ___ Reply to this item at:

[Wesnoth-bugs] [bug #20941] Keeping track of number of times recalled for each unit in a campaign.

Update of bug #20941 (project wesnoth): Severity: 3 - Normal = 1 - Wish ___ Follow-up Comment #1: I'm not really seeing a benefit here. If there is a unit I've found 15 times when I go to recall

[Wesnoth-bugs] [bug #20933] [base_unit] doesn't work for females

Update of bug #20933 (project wesnoth): Status:None = Fixed ___ Follow-up Comment #3: Fixed in 41f8816872584603bb9ba2c955947c078997f6a7. Note that the name of the female Mage type

[Wesnoth-bugs] [bug #20933] [base_unit] doesn't work for females

Update of bug #20933 (project wesnoth): Assigned to:None = jamit ___ Reply to this item at: http://gna.org/bugs/?20933 ___ Message sent

[Wesnoth-bugs] [bug #20684] filterwml does not match yes as true for unit variables any more

Update of bug #20684 (project wesnoth): Status:None = Fixed ___ Follow-up Comment #1: Fixed in revision 5900e96ffc544a7e497993eed89ca538c550749b.

[Wesnoth-bugs] [patch #3943] Set initial unit facing direction based on map location

Follow-up Comment #3, patch #3943 (project wesnoth): I had tried that in-game with the new dwarf fighters a while ago, but just to be sure, I tried it again, and also looked at the skeletons. I think it works well facing the recruiter. *shrug* Maybe I just have no eye for this sort of thing, but

[Wesnoth-bugs] [patch #3943] Set initial unit facing direction based on map location

Follow-up Comment #4, patch #3943 (project wesnoth): Hmm... actually, the complexity of this is not bad, if you take a less controlling approach. I've attached a file with a simpler implementation that you might want to consider. Instead of grouping hexes into nine collections, I gave each hex

[Wesnoth-bugs] [patch #3943] Set initial unit facing direction based on map location

Follow-up Comment #5, patch #3943 (project wesnoth): Please excuse me, that should have been fifteen, not nine, collections mentioned in my preceding comment. My bad. (I might have taken an analogy to DD's alignment system a bit too far. :) )

[Wesnoth-bugs] [bug #20923] Intermittent crash (runtime error) when using planning mode

Follow-up Comment #3, bug #20923 (project wesnoth): There are ways to provide more detail, other than a deterministic procedure. They are not as good as a deterministic procedure, but still better than just the error message. One the comes to mind is a screenshot showing the state of the game

[Wesnoth-bugs] [bug #20602] Animation glitch: Unit advancement/level up animations flicker

Update of bug #20602 (project wesnoth): Status: In Progress = Fixed ___ Follow-up Comment #5: Fixed in 8b33acca958f1973f760b7749e10758d7fdec426 (ugly Git revision number).

[Wesnoth-bugs] [bug #20704] [effect] apply_to=new_animation crashes the game later

Update of bug #20704 (project wesnoth): Status: In Progress = Fixed ___ Follow-up Comment #4: Fixed in 8733b8f1444cdf8aa5590e9992fbf66b8efa6cea.

[Wesnoth-bugs] [bug #20755] Mainline TROW distract ability requires strange workaround

Update of bug #20755 (project wesnoth): Status: In Progress = Fixed ___ Reply to this item at: http://gna.org/bugs/?20755 ___ Message sent

[Wesnoth-bugs] [bug #20800] Simply do not start : Segmentation Error (core dumped)

Update of bug #20800 (project wesnoth): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #4: OK, so it's not a

[Wesnoth-bugs] [bug #20704] [effect] apply_to=new_animation crashes the game later

Update of bug #20704 (project wesnoth): Status:None = In Progress Assigned to:None = jamit ___ Reply to this item at:

[Wesnoth-bugs] [bug #20800] Simply do not start : Segmentation Error (core dumped)

Follow-up Comment #2, bug #20800 (project wesnoth): The backtrace and log seem to indicate that you were attempting to load a saved game. Is that the case? The original report states the menu do not open, which I took to mean that you did not get to the main menu, much less past it and through

[Wesnoth-bugs] [bug #20704] [effect] apply_to=new_animation crashes the game later

Follow-up Comment #3, bug #20704 (project wesnoth): Fixing this at both ends would be cool, only... well, I suppose that is something to mention on the patch's page. ___ Reply to this item at: http://gna.org/bugs/?20704

[Wesnoth-bugs] [patch #3862] Fixed bug #20704: using 'apply_to=new_animation' with 'id'

Follow-up Comment #1, patch #3862 (project wesnoth): You might want to run this by boucman, as he added the cache in r46088 to deal with bug #16363. In particular, I notice that that bug was never confirmed fixed, so boucman might not realize he neglected to add the code that would populate the

[Wesnoth-bugs] [patch #3742] Inner variable for adjacent filter in abilities WML and TROW distract fix

Follow-up Comment #10, patch #3742 (project wesnoth): Since a fix is already prepared, you didn't really need to create a bug report, unless you're afraid I'll forget. ;) I brought up bug reports first to check to see if my search skills failed me. If others could also not find a bug report for

[Wesnoth-bugs] [bug #19924] MP Campaigns - Deleting units in recall list causes OOS

Follow-up Comment #5, bug #19924 (project wesnoth): Sorry, no, it is not a similar problem. Both problems do involve dismissing a unit, but this problem is about bad communication between clients, while the forum bug is about confusion within a single client. This problem occurs only in MP, while

[Wesnoth-bugs] [patch #3862] Fixed bug #20704: using 'apply_to=new_animation' with 'id'

Follow-up Comment #2, patch #3862 (project wesnoth): Correction to the preceding (thunderstruck's assessment and my tacit acceptance of that): the cache is implemented. The cache is populated because the built variable (removed by this patch) is a reference. It references an element in the cache,

  1   2   3   >