[Wesnoth-bugs] [patch #3275] AI - Spread poison around

Follow-up Comment #6, patch #3275 (project wesnoth): I think this patch gives poison positive weight when attacking a unit that will advance. Poison damage should probably be ignored in a kill-or-advance situation. This patch also appears to give poison its full weight when attacking a unit that

[Wesnoth-bugs] [bug #19656] [object]s with duration=turn are not removed on the first turn

Follow-up Comment #5, bug #19656 (project wesnoth): Sorry for not getting back to this sooner - the April 25th message corresponded with gna's mailer running out of disk space, so I had no idea that anyone had replied to this. For any WML author who does not like the intended behavior, a simple w

[Wesnoth-bugs] [bug #19666] When I resize windows during dialog I lose the menu buttons

Update of bug #19666 (project wesnoth): Status:None => Confirmed ___ Follow-up Comment #1: This often happens to me when I start Wesnoth into the test scenario in 1.11. It does indeed se

[Wesnoth-bugs] [bug #19663] Death animation gives away too much information when fog is enabled

Follow-up Comment #2, bug #19663 (project wesnoth): I disagree that this is too much information. Seeing the unit being attacked strikes me as a perfectly valid way to learn about the attack being used. ___ Reply to this item at:

[Wesnoth-bugs] [bug #19685] Request for a [detect] ability

Follow-up Comment #1, bug #19685 (project wesnoth): You want this ability to be able to suppress certain "hides" abilities, while leaving others active? I think this result might be more easily obtained by adding a StandardSideFilter to the [hides] tag that determines which sides the unit is hidd

[Wesnoth-bugs] [patch #3186] [event] name=movefrom and [event] name=movethrough

Update of patch #3186 (project wesnoth): Status: Ready For Test => Done ___ Follow-up Comment #25: Enemy units placed in a moving unit's path in an enter/exit hex event that allows undo will no

[Wesnoth-bugs] [bug #8166] A moveover event (similar to moveto)

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

[Wesnoth-bugs] [patch #1381] Updated patch for configurable village support (upkeep) - FT#6301

Update of patch #1381 (project wesnoth): Status: In Progress => Done ___ Follow-up Comment #13: Naturally, it also differs in all the ways that 1.11.0 differs from 1.7.9. __

[Wesnoth-bugs] [patch #1381] Updated patch for configurable village support (upkeep) - FT#6301

Update of patch #1381 (project wesnoth): Assigned to: gabba => brilliand ___ Reply to this item at: ___ Message sen

[Wesnoth-bugs] [patch #3186] [event] name=movefrom and [event] name=movethrough

Update of patch #3186 (project wesnoth): Status:None => Ready For Test Assigned to: boucman => brilliand ___ Follow-up Comment #23: I have now made p

[Wesnoth-bugs] [bug #19517] Young human sergeant is found before he is even seen

Update of bug #19517 (project wesnoth): Status: In Progress => Fixed ___ Follow-up Comment #4: Also copied the fix to the 1.10 branch (r53993). __

[Wesnoth-bugs] [bug #19517] Young human sergeant is found before he is even seen

Update of bug #19517 (project wesnoth): Status:None => In Progress Assigned to:None => brilliand ___ Follow-up Comment #2: Looks like the even

[Wesnoth-bugs] [bug #19658] In replays, units sometimes refresh movement when it is not their turn

Update of bug #19658 (project wesnoth): Status: In Progress => Fixed ___ Reply to this item at: ___ Message sent

[Wesnoth-bugs] [bug #19658] In replays, units sometimes refresh movement when it is not their turn

URL: Summary: In replays, units sometimes refresh movement when it is not their turn Project: Battle for Wesnoth Submitted by: brilliand Submitted on: Wed 25 Apr 2012 04:16:55 AM GMT Category:

[Wesnoth-bugs] [bug #19656] [object]s with duration=turn are not removed on the first turn

Update of bug #19656 (project wesnoth): Status: Confirmed => Fixed ___ Reply to this item at: ___ Message sent

[Wesnoth-bugs] [bug #19656] [object]s with duration=turn are not removed on the first turn

Update of bug #19656 (project wesnoth): Status:None => Confirmed ___ Reply to this item at: ___ Message sent

[Wesnoth-bugs] [bug #19656] [object]s with duration=turn are not removed on the first turn

Follow-up Comment #1, bug #19656 (project wesnoth): Similarly, units don't take poison damage on their first turn if poisoned before their side has had a turn. It appears that most of the start-of-turn calculations are skipped on a side's first turn. This should probably be changed. ___

[Wesnoth-bugs] [bug #19642] map_generation=default causes an error about missing usage= in map header

URL: Summary: map_generation=default causes an error about missing usage= in map header Project: Battle for Wesnoth Submitted by: brilliand Submitted on: Sat 14 Apr 2012 01:16:26 AM GMT Categor

[Wesnoth-bugs] [patch #3210] Add [object]duration=turn

Update of patch #3210 (project wesnoth): Status:None => Done ___ Follow-up Comment #2: Applied revision #53905. ___ Reply to

[Wesnoth-bugs] [patch #3186] [event] name=movefrom and [event] name=movethrough

Follow-up Comment #22, patch #3186 (project wesnoth): I haven't made much progress on the new version of the patch, as I've been busy with other things, so this is still a good time to make changes to that section of the code. Man, that's twice writing a wall of text and losing it. Short version

[Wesnoth-bugs] [patch #3186] [event] name=movefrom and [event] name=movethrough

Follow-up Comment #18, patch #3186 (project wesnoth): I have, in the past, coded something in WML that would be perfect for the enter_hex event: I made a scenario in which the terrain changed as units moved over it (to a terrain that was beneficial to that unit). At the time, all of the terrain c

[Wesnoth-bugs] [patch #3186] [event] name=movefrom and [event] name=movethrough

Follow-up Comment #16, patch #3186 (project wesnoth): jamit, I don't think putting enter_hex and exit_hex in surprise_movement_end() will work. If we required that those events not change any game state and just interrupt movement (and do anything important in moveto), then it would, but if the u

[Wesnoth-bugs] [patch #3186] [event] name=movefrom and [event] name=movethrough

Follow-up Comment #15, patch #3186 (project wesnoth): Yes, that would make the most sense. ___ Reply to this item at: ___ Message sent via/by Gna! http://gna.o

[Wesnoth-bugs] [patch #3186] [event] name=movefrom and [event] name=movethrough

Follow-up Comment #13, patch #3186 (project wesnoth): boucman: I'll live. I do see the sense in doing it that way. jamit: If there's going to be an "exit_hex" event, I think there should be an "enter_hex" event as well. The name just seems to imply that the opposite also exists (and "exit_hex"

[Wesnoth-bugs] [patch #3186] [event] name=movefrom and [event] name=movethrough

Follow-up Comment #10, patch #3186 (project wesnoth): Do any other events interrupt when [allow_undo] is not used? As I understand it, not using [allow_undo] allows the action to continue, but prevents it from being undone. [stop_action], by contrast, puts a stop to something; it's rather a diff

[Wesnoth-bugs] [patch #3209] Add [filter_vision] tag to SLF

Follow-up Comment #4, patch #3209 (project wesnoth): The wiki is updated. ___ Reply to this item at: ___ Message sent via/by Gna! http://gna.org/ ___

[Wesnoth-bugs] [patch #3211] Remove [object]unit_type= and [object]unit_gender=

URL: Summary: Remove [object]unit_type= and [object]unit_gender= Project: Battle for Wesnoth Submitted by: brilliand Submitted on: Tue 27 Mar 2012 01:42:43 PM GMT Priority: 5 - Normal

[Wesnoth-bugs] [patch #3210] Add [object]duration=turn

URL: Summary: Add [object]duration=turn Project: Battle for Wesnoth Submitted by: brilliand Submitted on: Tue 27 Mar 2012 01:30:43 PM GMT Priority: 5 - Normal Status: None

[Wesnoth-bugs] [patch #3194] Extend [filter_vision] to work in SLF, and partial fix to bug #19565

Follow-up Comment #3, patch #3194 (project wesnoth): 1. I've submitted patch #3208 to that end. 2-4. Submitted patch #3209. 5. Sounds like a good idea, but I'm not familiar with Wesnoth's deprecation practices, so I'll not do that immediately, anyway. I've attached a revised patch that only updat

[Wesnoth-bugs] [patch #3209] Add [filter_vision] tag to SLF

Follow-up Comment #1, patch #3209 (project wesnoth): Attached the WML that I used to test this patch (as a patch against scenario-test.cfg). (file #15433) ___ Additional Item Attachment: File name: test.patch Size:5 KB

[Wesnoth-bugs] [patch #3209] Add [filter_vision] tag to SLF

URL: Summary: Add [filter_vision] tag to SLF Project: Battle for Wesnoth Submitted by: brilliand Submitted on: Tue 27 Mar 2012 09:45:06 AM GMT Priority: 5 - Normal Status: Non

[Wesnoth-bugs] [patch #3208] Add support for ranges of sides to SSF

URL: Summary: Add support for ranges of sides to SSF Project: Battle for Wesnoth Submitted by: brilliand Submitted on: Tue 27 Mar 2012 08:10:37 AM GMT Priority: 5 - Normal Sta

[Wesnoth-bugs] [patch #3186] [event] name=movefrom and [event] name=movethrough

Follow-up Comment #8, patch #3186 (project wesnoth): Movethrough events only occur in unoccupied hexes. For occupied hexes, there's a "pass ally" event that fires (just before movethrough) once for every occupied hex that was moved through since the last unoccupied hex. Perhaps "movethrough" sho

[Wesnoth-bugs] [patch #3186] [event] name=movefrom and [event] name=movethrough

Follow-up Comment #6, patch #3186 (project wesnoth): While playing a campaign, I discovered that setting a goto on a unit that couldn't actually move any further caused the unit's HP bar and status orb to vanish. I've attached a cumulative patch that fixes this problem (and some other potential p

[Wesnoth-bugs] [patch #3186] [event] name=movefrom and [event] name=movethrough

Follow-up Comment #5, patch #3186 (project wesnoth): Erm, what I said about movefrom breaking replays... I meant $x2 and $y2, not $x1 and $x2. ___ Reply to this item at: _

[Wesnoth-bugs] [patch #3186] [event] name=movefrom and [event] name=movethrough

Follow-up Comment #4, patch #3186 (project wesnoth): Note to self: if/when this patch is applied, the following wiki pages should be changed to reflect this: http://wiki.wesnoth.org/FutureWML -Remove [event] name="move" http://wiki.wesnoth.org/EventWML -Add name=(movefrom|movethrough|pass ally) -N

[Wesnoth-bugs] [patch #3186] [event] name=movefrom and [event] name=movethrough

Follow-up Comment #3, patch #3186 (project wesnoth): One feature that has been conspicuously lacking in this patch so far is a convenient way to stop movement on a movethrough event, so I've added a [stop_action] tag for that purpose (it also works for stopping an attack during attack events). I

[Wesnoth-bugs] [patch #3186] [event] name=movefrom and [event] name=movethrough

Follow-up Comment #2, patch #3186 (project wesnoth): I chose the "trailing pointer" approach in order to give WML events (particularly "movethrough") ample opportunity to modify move-related information, such as the upcoming terrain, and have those changes to game state accounted for in the move.

[Wesnoth-bugs] [patch #3133] Movement algorithm

Follow-up Comment #7, patch #3133 (project wesnoth): I think my patch #3186 is a competitor to this patch. It revises move_unit() with a different purpose in mind (adding [event]name=movethrough), but it happens to fix the particular problem mentioned in the first comment to this patch.

[Wesnoth-bugs] [patch #3194] Extend [filter_vision] to work in SLF, and partial fix to bug #19565

Follow-up Comment #1, patch #3194 (project wesnoth): Since I've submitted a more targeted patch for just the Legend of Wesmere issue, I'm revising this patch to contain only enhancements to [filter_vision]. This new patch duplicates [filter_vision] for use in a standard location filter (as the pr

[Wesnoth-bugs] [bug #19565] [LoW-10] Event triggered before the cause is visible

Follow-up Comment #3, bug #19565 (project wesnoth): Submitted patch #3198 as a more complete fix for this bug that does not require any changes to C++ code or 1.11-only features. I'm hoping this means that it can be applied to both the 1.10 branch and the 1.11 branch. ___

[Wesnoth-bugs] [patch #3198] Fix for bug #19565

URL: Summary: Fix for bug #19565 Project: Battle for Wesnoth Submitted by: brilliand Submitted on: Wed 21 Mar 2012 01:14:39 PM GMT Priority: 5 - Normal Status: None

[Wesnoth-bugs] [bug #19565] [LoW-10] Event triggered before the cause is visible

Follow-up Comment #2, bug #19565 (project wesnoth): Submitted patch #3194 as a partial fix for this bug For a full fix, I suppose the yetis should get some sort of plausible "appear out of nowhere" animation when Krulg's location (12,11) is sighted. Right now, the yetis' intro animation doesn't

[Wesnoth-bugs] [patch #3194] Extend [filter_vision] to work in SLF, and partial fix to bug #19565

URL: Summary: Extend [filter_vision] to work in SLF, and partial fix to bug #19565 Project: Battle for Wesnoth Submitted by: brilliand Submitted on: Tue 20 Mar 2012 03:59:58 PM GMT Priority: 5

[Wesnoth-bugs] [bug #19565] [LoW-10] Event triggered before the cause is visible

Follow-up Comment #1, bug #19565 (project wesnoth): There's a todo about this on line 341 of {datacampaignsLegend_of_Wesmerescenarioschapter310_Cliffs_of_Thoria.cfg}. ___ Reply to this item at: _

[Wesnoth-bugs] [patch #3186] [event] name=movefrom and [event] name=movethrough

URL: Summary: [event] name=movefrom and [event] name=movethrough Project: Battle for Wesnoth Submitted by: brilliand Submitted on: Sun 18 Mar 2012 04:17:23 PM GMT Priority: 5 - Normal

[Wesnoth-bugs] [patch #3083] Extended drain (value, add, multiply, negative and fixed values)

Follow-up Comment #20, patch #3083 (project wesnoth): I don't think the changelog entries went in the right place. I had them in the right place for the revision that I was working from, but things have progressed since then. I've attached a patch that moves the changelog entries to the version

[Wesnoth-bugs] [patch #3083] Extended drain (value, add, multiply, negative and fixed values)

Follow-up Comment #19, patch #3083 (project wesnoth): Unsigned ints are also ints. I wanted to emphasize that I was changing it from unsigned to signed. ___ Reply to this item at: __

[Wesnoth-bugs] [patch #3083] Extended drain (value, add, multiply, negative and fixed values)

Follow-up Comment #16, patch #3083 (project wesnoth): Okay. Here's an incremental patch (to be applied on top of remove-unused.patch) that reverses the change to the signature of prob_matrix::xfer and several other variable type changes, and replaces all C-style casts with C++-style casts. I als

[Wesnoth-bugs] [patch #3083] Extended drain (value, add, multiply, negative and fixed values)

Follow-up Comment #13, patch #3083 (project wesnoth): Here's the fixed patch. (file #15353) ___ Additional Item Attachment: File name: remove-unused.patchSize:29 KB ___

[Wesnoth-bugs] [patch #3083] Extended drain (value, add, multiply, negative and fixed values)

Follow-up Comment #11, patch #3083 (project wesnoth): Done. (Cumulative patch attached.) (file #15342) ___ Additional Item Attachment: File name: final-fixes.patch Size:29 KB

[Wesnoth-bugs] [patch #3083] Extended drain (value, add, multiply, negative and fixed values)

Follow-up Comment #9, patch #3083 (project wesnoth): You mean the death animations not happening together? I don't see that as a big deal, but then I can see plenty of situations where a non-killing drain would actually be more useful (to the WML author), so fine by me. I've attached a new cumul

[Wesnoth-bugs] [patch #3083] Extended drain (value, add, multiply, negative and fixed values)

Follow-up Comment #7, patch #3083 (project wesnoth): Okay, I've fixed all of the problems that I've been able to find. It turns out I had accounted for both parties dying, but I had a bunch of problems related to negative numbers in unsigned variables; now that section of code has a bunch of sign

[Wesnoth-bugs] [patch #3083] Extended drain (value, add, multiply, negative and fixed values)

Follow-up Comment #6, patch #3083 (project wesnoth): Hmm, OK, changing that to (var > 0 ? var : -var) is easy enough. I've accounted for the "both units die" scenario for regular combat; what happens is the unit killed by the actual attack goes through its death (animation and events), then after

[Wesnoth-bugs] [patch #3083] Extended drain (value, add, multiply, negative and fixed values)

Follow-up Comment #3, patch #3083 (project wesnoth): No... that's not correct... Here are the options I'm looking at: 1. Drain effects work similarly to damage modifiers, with the base value being half of the damage dealt (against living) or zero (against nonliving) 2. Same as above, but the [dr

[Wesnoth-bugs] [patch #3083] Extended drain (value, add, multiply, negative and fixed values)

Follow-up Comment #2, patch #3083 (project wesnoth): Now I remember. The constructor for unit_abilities::effect disallows a negative multiplier, and I didn't want to change that (as it would mess with far more than just drain). So in order to get the effect of a negative multiplier, I needed to

[Wesnoth-bugs] [patch #3083] Extended drain (value, add, multiply, negative and fixed values)

Follow-up Comment #1, patch #3083 (project wesnoth): Correction: the drain parameters only behave as for leadership once neg-drain.patch has been applied. With only mul-drain.patch, the drain parameters behave more like the damage special does: add and subtract modify the actual amount, and sett

[Wesnoth-bugs] [patch #3083] Extended drain (value, add, multiply, negative and fixed values)

URL: Summary: Extended drain (value, add, multiply, negative and fixed values) Project: Battle for Wesnoth Submitted by: brilliand Submitted on: Fri 06 Jan 2012 11:15:10 AM GMT Priority: 5 - N

[Wesnoth-bugs] [bug #17527] Feeding ability doubles when ghast and necrophage are in same scenario

Follow-up Comment #6, bug #17527 (project wesnoth): This should be considered fixed, now that patch #2851 is committed. ___ Reply to this item at: ___ Message s

[Wesnoth-bugs] [patch #2851] Patch for bug #17527: Feeding ability doubles when ghast and necrophage are in same scenario

Follow-up Comment #19, patch #2851 (project wesnoth): Thonsew, you were going to apply my patch after I tested it, right? I have indeed tested it. ___ Reply to this item at: ___

[Wesnoth-bugs] [patch #2851] Patch for bug #17527: Feeding ability doubles when ghast and necrophage are in same scenario

Follow-up Comment #18, patch #2851 (project wesnoth): I've been able to compile Wesnoth and test my patch, and I'm satisfied that it works as intended. ___ Reply to this item at: ___

[Wesnoth-bugs] [patch #2851] Patch for bug #17527: Feeding ability doubles when ghast and necrophage are in same scenario

Follow-up Comment #15, patch #2851 (project wesnoth): Once one event with that ID has been loaded, any additional events with the same ID (which would include copies of the original) are simply ignored. Removing an event frees up its ID for reuse. ___

[Wesnoth-bugs] [patch #2851] Patch for bug #17527: Feeding ability doubles when ghast and necrophage are in same scenario

Follow-up Comment #13, patch #2851 (project wesnoth): The "name" of an [event] in WML is nothing like an ID - what it does is it indicates which event the [event] is listening on. Many [event]s will share the same name, which just mean that they are responding to the same game event. Nearly eve

[Wesnoth-bugs] [patch #2851] Patch for bug #17527: Feeding ability doubles when ghast and necrophage are in same scenario

Follow-up Comment #9, patch #2851 (project wesnoth): Yes, that strikes me as a rather bad idea. What if I need to make a unit that regains 1 HP every time a living unit dies anywhere? Or that gives all friendly units +5% to all defenses until the end of the turn when it dies? Events in unit ty

[Wesnoth-bugs] [patch #2851] Patch for bug #17527: Feeding ability doubles when ghast and necrophage are in same scenario

Follow-up Comment #7, patch #2851 (project wesnoth): I'm still not clear on what this scoping of events would even do. Would it make the "die" event in the Necrophage only activate when a Necrophage dies? (Obviously a bad idea.) Allowing an event to reference the unit type that it was included

[Wesnoth-bugs] [patch #2851] Patch for bug #17527: Feeding ability doubles when ghast and necrophage are in same scenario

Follow-up Comment #5, patch #2851 (project wesnoth): I propose this modified version of the patch, which implements the [event]id= and [event]remove= parameters. Unfortunately I haven't been able to test it thoroughly, due to difficulties compiling Wesnoth ( http://forums.wesnoth.org/viewtopic.p

[Wesnoth-bugs] [bug #18181] Provide a way to exclude already-downloaded addons from the addon list

URL: Summary: Provide a way to exclude already-downloaded addons from the addon list Project: Battle for Wesnoth Submitted by: brilliand Submitted on: Sat 04 Jun 2011 12:46:55 AM GMT Category:

[Wesnoth-bugs] [bug #17628] Downloading an add-on by its author deletes the working copy

Follow-up Comment #1, bug #17628 (project wesnoth): Indeed, there should probably be a way to filter out all add-ons that are already installed in any version (updating add-ons is a separate screen). Most likely that filter should be enabled by default, with a way to show all add-ons if for some

[Wesnoth-bugs] [bug #17651] [generator] tag gives a "not supported" error but works properly

URL: Summary: [generator] tag gives a "not supported" error but works properly Project: Battle for Wesnoth Submitted by: brilliand Submitted on: Sat 05 Feb 2011 12:54:01 AM GMT Category: Bug

[Wesnoth-bugs] [bug #17527] Feeding ability doubles when ghast and necrophage are in same scenario

Follow-up Comment #1, bug #17527 (project wesnoth): Hmm, I got logged as Anonymous. Just claiming this as my submission... ___ Reply to this item at: ___ Messa