Update of bug #23082 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?23082
___
Message sent
Update of bug #23082 (project wesnoth):
Status:None = Ready For Test
___
Follow-up Comment #1:
I don't have homebrew so if someone could see if I've fixed it, that would be
nice.
URL:
http://gna.org/bugs/?21465
Summary: Count of units that can move to a hex is useless
Project: Battle for Wesnoth
Submitted by: alarantalara
Submitted on: Thu 09 Jan 2014 03:54:45 PM EST
Category: Bug
URL:
http://gna.org/bugs/?21466
Summary: Selecting enemy units doesn't make sense
Project: Battle for Wesnoth
Submitted by: alarantalara
Submitted on: Thu 09 Jan 2014 03:58:58 PM EST
Category: Bug
URL:
http://gna.org/bugs/?21372
Summary: Pressing 't' to continue moving after sighting unit
no longer works
Project: Battle for Wesnoth
Submitted by: alarantalara
Submitted on: Tue 24 Dec 2013 04:33:12 PM EST
Category:
Update of patch #3799 (project wesnoth):
Status:None = Done
Assigned to:lipk = alarantalara
Open/Closed:Open = Closed
URL:
http://gna.org/patch/?3799
Summary: Fix colour issues on story screens.
Project: Battle for Wesnoth
Submitted by: alarantalara
Submitted on: Mon 25 Mar 2013 08:57:46 PM EDT
Priority: 5 - Normal
URL:
http://gna.org/bugs/?20468
Summary: replace_map doesn't update owned villages
Project: Battle for Wesnoth
Submitted by: alarantalara
Submitted on: Thu 31 Jan 2013 07:21:03 PM EST
Category: Bug
Update of bug #20456 (project wesnoth):
Status:None = Duplicate
___
Follow-up Comment #1:
Duplicate of bug #20373. Is likely a consequence of bug #20455.
Follow-up Comment #1, bug #20438 (project wesnoth):
Integer overflow or underflow is possible in 1.10 and earlier, though it
should require several effects of the same type (3-4) to be applied for it to
occur.
This therefore may already be fixed in 1.11, since the calculations there use
floating
Follow-up Comment #2, bug #20394 (project wesnoth):
It sounds like a player left and the host started the game at roughly the same
time. If the two messages crossed each other in transit, then another player
might see the first player leave before the game starts (while the host does
not). (End
Follow-up Comment #1, bug #20416 (project wesnoth):
I have also observed this on OS X, so it appears that the behavior not
occurring on Windows as mentioned in the forum is the unusual case.
___
Reply to this item at:
Follow-up Comment #4, bug #20373 (project wesnoth):
This forum post looks related:
http://forums.wesnoth.org/viewtopic.php?f=21t=38106
I suspect the issue is larger than just this campaign.
___
Reply to this item at:
Follow-up Comment #1, bug #20389 (project wesnoth):
Did you kill all the other transports?
___
Reply to this item at:
http://gna.org/bugs/?20389
___
Message sent via/by Gna!
Update of bug #20389 (project wesnoth):
Status:None = Fixed
Assigned to:None = alarantalara
___
Reply to this item at:
Follow-up Comment #3, bug #20373 (project wesnoth):
Someone (else?) has posted relevant save games here:
http://forums.wesnoth.org/viewtopic.php?f=4t=38087
Save files in OS X are located in /Users/your account/Library/Application
Support/Wesnoth (version)/
Update of bug #19827 (project wesnoth):
Status:None = Wont Fix
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #14401 (project wesnoth):
Status: Confirmed = Fixed
___
Reply to this item at:
http://gna.org/bugs/?14401
___
Message sent
Update of bug #20380 (project wesnoth):
Status:None = Duplicate
___
Follow-up Comment #1:
Looks like a duplicate of bug #16069.
Update of bug #20168 (project wesnoth):
Status:None = Invalid
___
Reply to this item at:
http://gna.org/bugs/?20168
___
Message sent
Update of bug #20168 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?20168
___
Message sent
Follow-up Comment #1, bug #20373 (project wesnoth):
Can you post the saves as well? Especially the one that crashes the game.
___
Reply to this item at:
http://gna.org/bugs/?20373
___
Update of bug #17807 (project wesnoth):
Status: Confirmed = Duplicate
___
Follow-up Comment #1:
bug #19666 duplicates this bug. Marking this bug as the duplicate as the other
has received more
Follow-up Comment #3, bug #19666 (project wesnoth):
This is a duplicate of bug #17807. Marking the older bug as the duplicate due
to lack of discussion there and because this one is more general.
Important points from other report:
Has existed since 1.9.4 (or earlier)
A workaround of resizing
Update of bug #17807 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?17807
___
Message sent
Update of patch #3570 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/patch/?3570
___
Message sent
Update of bug #19985 (project wesnoth):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #2:
If it's resolved
Follow-up Comment #3, bug #15771 (project wesnoth):
Testing in the new lobby on 1.10.5 shows that a scroll bar appears briefly,
then the text rewraps itself to fit and the scroll bar goes away. So it
appears to work there too.
___
Reply to
Update of bug #20292 (project wesnoth):
Status:None = Ready For Test
___
Follow-up Comment #3:
This appears to have been fixed in 1.11.1. I wouldn't be surprised if r55800
(which fixed a
Update of bug #19708 (project wesnoth):
Status:None = Duplicate
___
Follow-up Comment #1:
Marking as a duplicate of bug #20268 as that bug report is concerned with the
same issue but has
Follow-up Comment #2, bug #20268 (project wesnoth):
bug #19708 has been marked as a duplicate of this bug.
___
Reply to this item at:
http://gna.org/bugs/?20268
___
Message sent via/by Gna!
Update of bug #18550 (project wesnoth):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #1:
A is implemented in
Update of bug #20192 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?20192
___
Message sent
Update of bug #19595 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19595
___
Message sent
Update of bug #19303 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19303
___
Message sent
Update of bug #16772 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?16772
___
Message sent
Update of bug #20035 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?20035
___
Message sent
Follow-up Comment #5, bug #20343 (project wesnoth):
The tile description is also effectively unchangeable. Overlay descriptions
are supposed to override descriptions for the base terrain and it makes sense
to do so in every case but this (forests, mushroom groves, the castle overlay
on all other
Update of bug #8096 (project wesnoth):
Status:None = Ready For Test
Assigned to:mordante = shadowmaster
___
Follow-up Comment #3:
I believe the new
Update of bug #13449 (project wesnoth):
Status:None = Fixed
___
Follow-up Comment #3:
The new hotkey dialog in 1.11.0+svn truncates the text and adds ellipses when
the text becomes
Follow-up Comment #4, bug #20322 (project wesnoth):
Apparently this report represents more than one bug.
The included sample code does indeed no longer cause problems.
However, the case where I originally found the problem still has OOS occur.
I originally found the problem in Lua AI code.
Update of bug #13119 (project wesnoth):
Status:None = Ready For Test
Assigned to:None = alarantalara
___
Follow-up Comment #7:
The experimental AI
Follow-up Comment #2, bug #19353 (project wesnoth):
Is this considered to be solved yet?
___
Reply to this item at:
http://gna.org/bugs/?19353
___
Message sent via/by Gna!
http://gna.org/
Update of bug #16600 (project wesnoth):
Item Group: None of the others = Artificial Intelligence
___
Reply to this item at:
http://gna.org/bugs/?16600
___
Message sent
Follow-up Comment #1, bug #15919 (project wesnoth):
The key assumes that the image is 72x72 and places it so that top left of the
image and hex match.
There are two ways around this.
1) Use the halo key which centers the image.
2) Use BLIT to paste the image where you want on top of the image
Follow-up Comment #5, bug #20322 (project wesnoth):
Or maybe not. The AI appears to run at odd times.
I just ran into something that demonstrates that side turn events run after
the AI starts actions.
That is, the AI ran, found its recruitment list and picked a unit.
Then a side turn event
Update of bug #19353 (project wesnoth):
Status:None = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #20162 (project wesnoth):
Status:None = Fixed
___
Follow-up Comment #6:
Tested at r55803 - appears to work properly.
Update of bug #19595 (project wesnoth):
Status:None = Fixed
Assigned to:None = alarantalara
___
Reply to this item at:
Update of bug #20202 (project wesnoth):
Status: Need Info = Duplicate
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #16772 (project wesnoth):
Status: In Progress = Fixed
Assigned to: zookeeper = alarantalara
___
Reply to this item at:
Update of bug #15771 (project wesnoth):
Status:None = Need Info
___
Follow-up Comment #1:
Testing a long string in 1.8, 1.10 and 1.11 all show wrapping occurs properly.
Exactly what text
Update of bug #15771 (project wesnoth):
Status: Need Info = Works For Me
___
Reply to this item at:
http://gna.org/bugs/?15771
___
Message sent
Update of bug #11837 (project wesnoth):
Item Group: None of the others = Artificial Intelligence
___
Reply to this item at:
http://gna.org/bugs/?11837
___
Message sent
Follow-up Comment #7, bug #20251 (project wesnoth):
Ctrl+space doesn't work in 1.10.5 either so I think I can consider it a bug
unrelated to the issue originally reported.
'=' as a hotkey seems to be a display issue, not a functional one, since it
works but isn't displayed properly in the
Follow-up Comment #1, bug #20322 (project wesnoth):
This does have the workaround of ensuring that any private units created
contain no random content (name, gender, traits, etc.)
___
Reply to this item at:
http://gna.org/bugs/?20322
Update of bug #20249 (project wesnoth):
Status: In Progress = Fixed
___
Reply to this item at:
http://gna.org/bugs/?20249
___
Message sent
Update of bug #20251 (project wesnoth):
Status: In Progress = Fixed
___
Reply to this item at:
http://gna.org/bugs/?20251
___
Message sent
Update of bug #20191 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?20191
___
Message sent
Update of bug #20252 (project wesnoth):
Status: In Progress = Fixed
___
Reply to this item at:
http://gna.org/bugs/?20252
___
Message sent
URL:
http://gna.org/bugs/?20322
Summary: Private units created with Lua cause OOS in replays
Project: Battle for Wesnoth
Submitted by: alarantalara
Submitted on: Thu 22 Nov 2012 09:20:46 PM EST
Category: Bug
Update of bug #20202 (project wesnoth):
Status:None = Need Info
___
Reply to this item at:
http://gna.org/bugs/?20202
___
Message sent
Update of bug #20242 (project wesnoth):
Status:None = Duplicate
___
Follow-up Comment #1:
Duplicate of bug #20191
___
Reply to
Follow-up Comment #2, bug #20242 (project wesnoth):
This will not change in 1.10.x to avoid OOS problems. It may change in 1.11.
You can probably work around the problem in 1.10 by applying two effects in
the object, each with a filter, one of which only applies if the defense is
negative and a
Update of bug #20208 (project wesnoth):
Status: Fixed = In Progress
Assigned to:None = ayne
___
Follow-up Comment #5:
The attached
Update of bug #20218 (project wesnoth):
Status:None = Invalid
___
Reply to this item at:
http://gna.org/bugs/?20218
___
Message sent
Update of bug #20218 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?20218
___
Message sent
Follow-up Comment #2, bug #20211 (project wesnoth):
What I'm seeing happening is that the after the scenario ends in victory, the
game recognizes that it ended in the prestart event.
There are no teams defined in the scenario, so teams_.empty() evaluates to
true at line 432 of
Update of bug #19303 (project wesnoth):
Status: In Progress = Fixed
Assigned to:crab = alarantalara
___
Reply to this item at:
Update of bug #20208 (project wesnoth):
Status:None = Fixed
___
Reply to this item at:
http://gna.org/bugs/?20208
___
Message sent
URL:
http://gna.org/bugs/?20211
Summary: Story only scenarios with victory in prestart should
not require side definition
Project: Battle for Wesnoth
Submitted by: alarantalara
Submitted on: Tue 02 Oct 2012 01:50:15 AM EDT
Update of bug #20178 (project wesnoth):
Status:None = Duplicate
___
Follow-up Comment #1:
Crash is duplicate of bug #20208, which includes other scenarios in which it
occurs.
Please
Update of bug #20207 (project wesnoth):
Status:None = Fixed
Assigned to:None = alarantalara
___
Reply to this item at:
Update of bug #19762 (project wesnoth):
Status:None = Duplicate
___
Follow-up Comment #3:
Duplicate of bug #13242.
___
Reply to
Update of bug #19762 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19762
___
Message sent
Update of bug #16908 (project wesnoth):
Status:None = Works For Me
___
Follow-up Comment #1:
This problem appears to have been resolved at some point before 1.10.4 since I
cannot reproduce
Follow-up Comment #4, patch #3360 (project wesnoth):
Would be worth checking to see if this patch also addresses bug bug #16220
___
Reply to this item at:
http://gna.org/patch/?3360
___
Update of bug #20192 (project wesnoth):
Severity: 3 - Normal = 2 - Minor
Status:None = In Progress
Assigned to:None = alarantalara
Update of bug #20192 (project wesnoth):
Status: In Progress = Fixed
___
Reply to this item at:
http://gna.org/bugs/?20192
___
Message sent
Follow-up Comment #1, bug #20191 (project wesnoth):
This is intended. Negative defenses have special meaning and are also used by
the feral trait to indicate that this defense value cannot be improved on.
A fix to support WML changes would probably mean reversing modifications on
negative
Update of bug #20113 (project wesnoth):
Assigned to:None = fendrin
___
Reply to this item at:
http://gna.org/bugs/?20113
___
Message sent
Update of bug #20102 (project wesnoth):
Status:None = Invalid
___
Reply to this item at:
http://gna.org/bugs/?20102
___
Message sent
Update of bug #19949 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19949
___
Message sent
Update of bug #19753 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19753
___
Message sent
Update of bug #19996 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19996
___
Message sent
Update of bug #19995 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19995
___
Message sent
Update of bug #20102 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?20102
___
Message sent
Follow-up Comment #5, bug #19622 (project wesnoth):
Sounds fine to me. I think it's a duplicate of a more recently posted bug that
had better steps to reproduce anyway.
___
Reply to this item at:
http://gna.org/bugs/?19622
URL:
http://gna.org/bugs/?20035
Summary: Crash in whiteboard when trying to attack
Project: Battle for Wesnoth
Submitted by: alarantalara
Submitted on: Mon 06 Aug 2012 06:01:29 PM EDT
Category: Bug
Update of bug #20035 (project wesnoth):
Assigned to:None = gabba
___
Reply to this item at:
http://gna.org/bugs/?20035
___
Message sent
Update of bug #19995 (project wesnoth):
Status:None = Fixed
___
Reply to this item at:
http://gna.org/bugs/?19995
___
Message sent
Update of bug #19996 (project wesnoth):
Status:None = Fixed
___
Reply to this item at:
http://gna.org/bugs/?19996
___
Message sent
Update of bug #20011 (project wesnoth):
Assigned to:None = beetlenaut
___
Follow-up Comment #1:
There is also a stunning attack in Under the Burning Suns, but the description
there says it is
Follow-up Comment #2, bug #19995 (project wesnoth):
I now have a recruit list that matches the previous scenario with that patch.
It appears to not be the correct set of units (since it was supposed to be
changed), but that may be a bug in the scenario, not the engine, so I'll check
that further
Follow-up Comment #2, bug #19996 (project wesnoth):
The save was created yesterday during playtesting against the revision
specified. I've attached the save in question.
(file #16234)
___
Additional Item Attachment:
File name:
Update of bug #19996 (project wesnoth):
Summary: Start of scenario saves do not give carryover gold
when loaded = Start of scenario saves always use old carryover
___
Follow-up Comment #3:
I've just tested and discovered
Follow-up Comment #3, bug #19995 (project wesnoth):
I've followed the recruit setting path for the scenario, and the recruit list
appears to be correct. Therefore, I'm happy with this patch.
___
Reply to this item at:
URL:
http://gna.org/bugs/?19995
Summary: Scenario starts do not honor recruit list from
previous scenario
Project: Battle for Wesnoth
Submitted by: alarantalara
Submitted on: Sat 28 Jul 2012 11:41:03 AM EDT
Category: Bug
Update of bug #19995 (project wesnoth):
Assigned to:None = ayne
___
Reply to this item at:
http://gna.org/bugs/?19995
___
Message sent
URL:
http://gna.org/bugs/?19996
Summary: Start of scenario saves do not give carryover gold
when loaded
Project: Battle for Wesnoth
Submitted by: alarantalara
Submitted on: Sat 28 Jul 2012 01:35:41 PM EDT
Category: Bug
1 - 100 of 276 matches
Mail list logo