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
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
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
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:
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
Update of patch #3186 (project wesnoth):
Status:None = Ready For Test
Assigned to: boucman = brilliand
___
Follow-up Comment #23:
I have now made
Update of patch #1381 (project wesnoth):
Assigned to: gabba = brilliand
___
Reply to this item at:
http://gna.org/patch/?1381
___
Message sent
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.
Update of bug #8166 (project wesnoth):
Status:None = Fixed
Assigned to:None = brilliand
___
Reply to this item at:
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
Update of bug #19517 (project wesnoth):
Status:None = In Progress
Assigned to:None = brilliand
___
Follow-up Comment #2:
Looks like the event
URL:
http://gna.org/bugs/?19658
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:
Update of bug #19658 (project wesnoth):
Status: In Progress = Fixed
___
Reply to this item at:
http://gna.org/bugs/?19658
___
Message sent
Update of bug #19656 (project wesnoth):
Status:None = Confirmed
___
Reply to this item at:
http://gna.org/bugs/?19656
___
Message sent
Update of bug #19656 (project wesnoth):
Status: Confirmed = Fixed
___
Reply to this item at:
http://gna.org/bugs/?19656
___
Message sent
Update of patch #3210 (project wesnoth):
Status:None = Done
___
Follow-up Comment #2:
Applied revision #53905.
___
Reply to
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
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
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
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 seems
Follow-up Comment #15, patch #3186 (project wesnoth):
Yes, that would make the most sense.
___
Reply to this item at:
http://gna.org/patch/?3186
___
Message sent via/by Gna!
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
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 should
URL:
http://gna.org/patch/?3208
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
URL:
http://gna.org/patch/?3209
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: None
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
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
URL:
http://gna.org/patch/?3210
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
URL:
http://gna.org/patch/?3211
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
Follow-up Comment #4, patch #3209 (project wesnoth):
The wiki is updated.
___
Reply to this item at:
http://gna.org/patch/?3209
___
Message sent via/by Gna!
http://gna.org/
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
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.
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
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)
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:
http://gna.org/patch/?3186
URL:
http://gna.org/patch/?3198
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
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.
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
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.
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:
http://gna.org/bugs/?19565
URL:
http://gna.org/patch/?3194
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 -
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
URL:
http://gna.org/patch/?3186
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
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
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:
http://gna.org/patch/?3083
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
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
___
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
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
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
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
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
URL:
http://gna.org/patch/?3083
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 -
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
Follow-up Comment #6, bug #17527 (project wesnoth):
This should be considered fixed, now that patch #2851 is committed.
___
Reply to this item at:
http://gna.org/bugs/?17527
___
Message
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:
http://gna.org/patch/?2851
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:
http://gna.org/patch/?2851
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
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.
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
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
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 (
URL:
http://gna.org/bugs/?18181
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:
URL:
http://gna.org/bugs/?17651
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
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
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:
http://gna.org/bugs/?17527
___
66 matches
Mail list logo
