Follow-up Comment #2, bug #12871 (project wesnoth):
I don't seem to be able to reproduce this with trunk r52175 (on windows) no
matter what resolution. I think I remember seeing it at some spot but I think
it's long gone. Tried both resolutions mentioned as system and ingame
settings.
Update of bug #18694 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?18694
___
Nachricht
Update of bug #19081 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19081
___
Nachricht
Update of bug #19106 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19106
___
Nachricht
Update of bug #19108 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19108
___
Nachricht
Follow-up Comment #4, bug #19089 (project wesnoth):
The question was about the wesnoth version not the MacOs version. Please try
reproducing with wesnoth 1.9.12.
Anyway, does that mean that you can't reproduce after upgrading MacOs ? If so
the bug is invalid.
Update of bug #19028 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19028
___
Nachricht
Update of bug #18968 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?18968
___
Nachricht
Update of bug #19096 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19096
___
Nachricht
Update of bug #19095 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19095
___
Nachricht
Update of bug #19061 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19061
___
Nachricht
Update of bug #19052 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?19052
___
Nachricht
Update of bug #18992 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?18992
___
Nachricht
Update of bug #18976 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?18976
___
Nachricht
Update of bug #18971 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?18971
___
Nachricht
Update of bug #18774 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?18774
___
Nachricht
Update of bug #18654 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?18654
___
Nachricht
Update of bug #17799 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?17799
___
Nachricht
Follow-up Comment #1, bug #18284 (project wesnoth):
3. The dialog cannot be closed by a mousepress like a normal small objectives
dialog. This happens even directly after opening the dialog without the bad
look. I don't know whether this was already present when I made the report.
Note that
Update of bug #16274 (project wesnoth):
Category: Bug = Feature Request
___
Follow-up Comment #1:
-I consider this a FR.
-I consider labels part of the gamestate, thus it seems problematic to
Update of bug #16274 (project wesnoth):
Summary: ignore list does not block labels set by a player
= please let ignore list block labels set by a player
___
Reply to this item at:
http://gna.org/bugs/?16274
Follow-up Comment #2, bug #18284 (project wesnoth):
Part 1) seems reported separately as bug #19121. The patch attached to that
report fixes 1) for me.
___
Reply to this item at:
http://gna.org/bugs/?18284
Follow-up Comment #1, bug #19086 (project wesnoth):
-The usage of unit.id is problematic since the engine normally never uses the
wml-definable id=, instead it uses underlying_id to refer to units (which you
need to access via the .__cfg field atm.)
-If you submit the code in the form of a diff
Update of bug #19083 (project wesnoth):
Release: 1.8.6 = 1.9.10
___
Reply to this item at:
http://gna.org/bugs/?19083
___
Nachricht
Update of bug #19074 (project wesnoth):
Severity: 2 - Minor = 3 - Normal
Priority: 3 - Low = 5 - Normal
___
Reply to this item at:
Update of bug #19106 (project wesnoth):
Status:None = Duplicate
Assigned to:None = gabba
___
Follow-up Comment #1:
probably duplicate
Follow-up Comment #1, bug #19074 (project wesnoth):
shadowmaster points out some important info:
[20:04] shadowmasteranonymissimus, AI0867 : the segfault is caused by an
unchecked vector access when trying to locate the first argument of an
inclusion
[20:04] shadowmasterthe easiest way
Follow-up Comment #3, bug #19083 (project wesnoth):
Ah yes. Thanks for the perfect description, could you please attach a
savegame from before the attack ?
This is actually a known bug (known by me at least) and the remainder of bug
#18157 after the partial fix for that one. It can be worked
Follow-up Comment #2, bug #18157 (project wesnoth):
see also bug #18157
___
Reply to this item at:
http://gna.org/bugs/?18157
___
Nachricht geschickt von/durch Gna!
http://gna.org/
Update of bug #19083 (project wesnoth):
Summary: Lagged attack makes a timed game crash on timer
expiration = OOS when time is short to attack
___
Follow-up Comment #4:
A good way to reproduce is to open the damage
Update of bug #19089 (project wesnoth):
Status:None = Need Info
___
Follow-up Comment #2:
We're in feature freeze for the next stable and nothing will be fixed for 1.8
anymore. Please
Follow-up Comment #8, bug #18868 (project wesnoth):
see also bug #19084
___
Reply to this item at:
http://gna.org/bugs/?18868
___
Nachricht geschickt von/durch Gna!
http://gna.org/
Follow-up Comment #1, bug #19084 (project wesnoth):
see also bug #18868
(looks like a duplicate, but I'm not sure)
___
Reply to this item at:
http://gna.org/bugs/?19084
___
Nachricht
Follow-up Comment #2, bug #15567 (project wesnoth):
see also bug #18868, bug #19084
___
Reply to this item at:
http://gna.org/bugs/?15567
___
Nachricht geschickt von/durch Gna!
Update of bug #19081 (project wesnoth):
Severity: 3 - Normal = 4 - Important
Priority: 5 - Normal = 7 - High
Assigned to:None = gabba
Follow-up Comment #1, bug #19083 (project wesnoth):
-1.8 is outdated by now since we're in feature freeze for the next stable. So
you should really reproduce with 1.9 if you can since nothing will be fixed in
the 1.8 source any more.
Maybe if I attempted to start Wesnoth twice, and multiplay
Follow-up Comment #3, bug #18968 (project wesnoth):
These are labels not dialogs.
I only see that some important labels have words in all-caps and many others
don't. So what ? Things are perfectly functional.
Please provide a patch which does the job if you think that this is something
important
Update of bug #18969 (project wesnoth):
Status:None = Postponed
Assigned to:None = anonymissimus
___
Follow-up Comment #1:
Not fixable
Update of bug #18968 (project wesnoth):
Status:None = Wont Fix
___
Follow-up Comment #1:
Marking won't fix:
-Not fixable currently due to string freeze.
-Where are there all-caps words
Update of bug #18969 (project wesnoth):
Severity: 3 - Normal = 2 - Minor
Priority: 5 - Normal = 3 - Low
___
Reply to this item at:
URL:
http://gna.org/bugs/?19074
Summary: preprocessor gets confused by nested s
Project: Battle for Wesnoth
Submitted by: anonymissimus
Submitted on: Mo 28 Nov 2011 21:57:03 GMT
Category: Bug
Severity: 2
Update of bug #19058 (project wesnoth):
Status:None = Fixed
Assigned to:None = espreon
___
Reply to this item at:
Update of bug #19028 (project wesnoth):
Status:None = Works For Me
___
Follow-up Comment #1:
Appears to works for me.
With a fresh preferences file and the setting enabled I can click on
Follow-up Comment #3, bug #19028 (project wesnoth):
In my previous post that should have been EncyclopediaGeographyMorogor (the
drake island).
___
Reply to this item at:
http://gna.org/bugs/?19028
Update of bug #16299 (project wesnoth):
Status: Ready For Test = None
Assigned to: anonymissimus = None
___
Follow-up Comment #18:
It seems
Update of bug #18809 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?18809
___
Nachricht
Update of bug #19055 (project wesnoth):
Severity: 5 - Blocker = 4 - Important
___
Reply to this item at:
http://gna.org/bugs/?19055
___
Nachricht
Update of bug #18877 (project wesnoth):
Assigned to:None = upthorn
___
Follow-up Comment #7:
upthorn, assigning to you as the coder of the persistent variables feature.
Do you think it
Follow-up Comment #11, bug #18694 (project wesnoth):
Reproducing is (actually was) easy IIRC; just plan a move with a unit and
then kill this unit. I don't remember whether it needed to be networked mp or
local was enough.
But as I said this did no longer reproduce.
Update of bug #19052 (project wesnoth):
Assigned to:None = anonymissimus
___
Reply to this item at:
http://gna.org/bugs/?19052
___
Nachricht
Update of bug #19052 (project wesnoth):
Status:None = Fixed
___
Follow-up Comment #3:
Well, the engine is right in crashing here so to say, it's not a tag
modifyable for users. Now
URL:
http://gna.org/bugs/?19056
Summary: gui stuff not updated if player disconnects or
leaves while it's his turn
Project: Battle for Wesnoth
Submitted by: anonymissimus
Submitted on: Do 24 Nov 2011 19:00:37 GMT
Follow-up Comment #15, bug #16299 (project wesnoth):
see also bug #19056
___
Reply to this item at:
http://gna.org/bugs/?16299
___
Nachricht geschickt von/durch Gna!
http://gna.org/
Update of bug #16299 (project wesnoth):
Assigned to:None = anonymissimus
___
Reply to this item at:
http://gna.org/bugs/?16299
___
Nachricht
Follow-up Comment #1, bug #19056 (project wesnoth):
Most likely introduced by r46027. This moved the according calls from a
function which was called from playmp_controller::play_side upon
player_type_changed_ == true into the side init code which is not called and
should not, since this
Update of bug #19043 (project wesnoth):
Assigned to:None = fendrin
___
Follow-up Comment #1:
It seems it's enough to put an invalid advances_to= into any unit type. (I
used Custom Unit in
Follow-up Comment #5, bug #18996 (project wesnoth):
Because I always prefer lua snippets as test cases due to their ability to
reflect changes on the fly without relaunching the scenario or even wesnoth,
which takes several minutes in case I'm running it under the MSVC debugger and
is still very
Follow-up Comment #14, bug #16299 (project wesnoth):
I feel like giving up now. I'm not satisfied with the ugly hack and it didn't
even work at all so there must be something else I don't understand.
I don't think that the server is involved or responsible, that is, the data
received appears ok.
Update of bug #18992 (project wesnoth):
Status: Confirmed = Fixed
Assigned to: fendrin = gabba
___
Follow-up Comment #8:
I'm marking this
Update of bug #17277 (project wesnoth):
Open/Closed: Closed = Open
___
Reply to this item at:
http://gna.org/bugs/?17277
___
Nachricht
Follow-up Comment #11, bug #17277 (project wesnoth):
Perhaps upon restoring the real unit map, the whiteboard should check whether
there are any collisions (coordinate-wise) and if so, delete the according
move/recruit/whatever plan, or delete all plans starting with the first
collision.
Follow-up Comment #4, patch #3040 (project wesnoth):
1) is an excellent question - this is not a value assignment,
local wml_actions
points to the same table
wesnoth.wml_actions
points to. Meaning if one changes, the other one (the exact same one and
only) does simultaneously. So there's no
Follow-up Comment #1, bug #18996 (project wesnoth):
A small script such as this
++
local rand = 0
for i = 0,10, 1 do
rand = math.max(rand, helper.rand(1..9))
end
wesnoth.message(tostring(rand))
--
shows the limitation. In this case I
Update of bug #18992 (project wesnoth):
Assigned to:None = fendrin
___
Follow-up Comment #3:
backtrace
++
Program received signal SIGTRAP, Trace/breakpoint trap.
0x77c05b62 in
Update of bug #18972 (project wesnoth):
Status:None = Invalid
___
Follow-up Comment #1:
That's the way the wesnoth UI works. For instance, an attacker hits event
needs to be executed
Update of bug #18972 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?18972
___
Nachricht
Follow-up Comment #4, bug #18977 (project wesnoth):
Is the way to reproduce (step 2 3) actually correct ?
There are sometimes bugs that need a lua error.
I managed to reproduce a crash a bit differently in the test scenario; it
looks as if these lua errors corrupt memory.
A valgrind log for
Follow-up Comment #4, bug #18809 (project wesnoth):
(Also, there is no reason why the lich sprite should blink, his wml
description hasn't been modified/mixed/whatever, he's a normal lich like in
every other scenario.)
___
Reply to this
Update of bug #16148 (project wesnoth):
Assigned to:mordante = None
___
Follow-up Comment #4:
I'm unassigning this from mordante. It was assigned to him since apparently
silene thought it
URL:
http://gna.org/bugs/?18983
Summary: uploading addon requires clicking on download
Project: Battle for Wesnoth
Submitted by: anonymissimus
Submitted on: Fr 11 Nov 2011 20:13:03 GMT
Category: Bug
Update of bug #18977 (project wesnoth):
Status: Ready For Test = Fixed
___
Reply to this item at:
http://gna.org/bugs/?18977
___
Nachricht
URL:
http://gna.org/bugs/?18984
Summary: networked mp game with non-idle AI crashes for
non-host
Project: Battle for Wesnoth
Submitted by: anonymissimus
Submitted on: Fr 11 Nov 2011 21:52:21 GMT
Category: Bug
Update of bug #18984 (project wesnoth):
Assigned to:None = fendrin
___
Follow-up Comment #1:
I suppose it is caused by fendrin's recent recruit/recall from
modifications...
Follow-up Comment #2, bug #18984 (project wesnoth):
Maybe the from data isn't sent over the network ? It apparently is done for
the human enemy. Perhaps that's the purpose of the functions in the ai area
which you didn't yet care for (I think). If so, the accessed leader u in
replay.cpp:900 is
Follow-up Comment #3, bug #18984 (project wesnoth):
Not in 1.9.10 yet, so yeah.
___
Reply to this item at:
http://gna.org/bugs/?18984
___
Nachricht geschickt von/durch Gna!
Update of bug #18966 (project wesnoth):
Status:None = Fixed
Assigned to:None = anonymissimus
___
Reply to this item at:
http://gna.org
Update of bug #18893 (project wesnoth):
Status: Postponed = Ready For Test
___
Reply to this item at:
http://gna.org/bugs/?18893
___
Nachricht
Update of bug #18869 (project wesnoth):
Status:None = Fixed
Assigned to: wintermute = anonymissimus
___
Follow-up Comment #1:
Fixed in r11684
Follow-up Comment #2, bug #18869 (project wesnoth):
Btw I also followed your pattern suggestion (since I'm sure you know that
better ;))
___
Reply to this item at:
http://gna.org/bugs/?18869
Update of bug #18893 (project wesnoth):
Status: Ready For Test = In Progress
___
Follow-up Comment #6:
This is pretty bad. Please post your wml testcase.
Follow-up Comment #7, bug #18893 (project wesnoth):
No testcase needed. These error messages are invalid. The fix would be to
delay variable substitution much more which requires refactoring a lot of
called subfunctions. I don't feel like doing it pre-1.10 since this could
cause a lot of bugs,
Update of bug #18893 (project wesnoth):
Status: In Progress = Postponed
___
Reply to this item at:
http://gna.org/bugs/?18893
___
Nachricht
Follow-up Comment #1, patch #3040 (project wesnoth):
Well -
1. We're in feature freeze...
2. You could've used
local wml_actions = wesnoth.wml_actions
...
wml_actions.kill({})
...
etc
3. Do note that calling wesnoth.wml_actions.tag(cfg) isn't equivalent to
wesnoth.fire(tag, cfg). For tags
Follow-up Comment #2, patch #3040 (project wesnoth):
The line 191 could be changed like so probably:
return function(cfg) wesnoth.wml_actions[n](wesnoth.tovconfig(cfg or {})) end
___
Reply to this item at:
http://gna.org/patch/?3040
Update of bug #18893 (project wesnoth):
Status: Confirmed = Ready For Test
___
Reply to this item at:
http://gna.org/bugs/?18893
___
Nachricht
Follow-up Comment #1, bug #18931 (project wesnoth):
As a note, in case the recall was triggered by action wml it works.
This works ingame and in the replay:
++
[event]
name=moveto
[unit]
type=Troll
Follow-up Comment #2, bug #18931 (project wesnoth):
I've removed the references to $second_unit in recall events and
[recall][secondary_unit] in changelog and wiki. This should be temporarily.
___
Reply to this item at:
Update of bug #12962 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?12962
___
Nachricht
Update of bug #16076 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?16076
___
Nachricht
Update of bug #16089 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?16089
___
Nachricht
Update of bug #16111 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?16111
___
Nachricht
Update of bug #16141 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?16141
___
Nachricht
Update of bug #16165 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?16165
___
Nachricht
Update of bug #16259 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?16259
___
Nachricht
Update of bug #16577 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?16577
___
Nachricht
Update of bug #16821 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?16821
___
Nachricht
Update of bug #17023 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?17023
___
Nachricht
Update of bug #17038 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?17038
___
Nachricht
Update of bug #17365 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?17365
___
Nachricht
Update of bug #17527 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?17527
___
Nachricht
401 - 500 of 1187 matches
Mail list logo
