Follow-up Comment #2, bug #16172 (project wesnoth):
3) has been implemented, just like for loyal it sill only five you the effect
not the trait.
___
Reply to this item at:
http://gna.org/bugs/?16172
URL:
http://gna.org/bugs/?22956
Summary: Mp campaign list shows unit icons
Project: Battle for Wesnoth
Submitted by: gfgtdf
Submitted on: Fr 14 Nov 2014 16:37:29 UTC
Category: Bug
Severity: 3 - Normal
Update of bug #22890 (project wesnoth):
Status: Need Info = None
Open/Closed: Closed = Open
___
Follow-up Comment #2:
y i can definitely
Update of bug #22956 (project wesnoth):
Severity: 3 - Normal = 2 - Minor
Assigned to:None = fendrin
___
Follow-up Comment #1:
ok i found out that
Update of bug #16850 (project wesnoth):
Status:None = Wont Fix
___
Follow-up Comment #3:
like i said in https://gna.org/bugs/index.php?16820 killing all units with
[kill] is not
Update of bug #22546 (project wesnoth):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #21798 (project wesnoth):
Status: Ready For Test = Fixed
___
Reply to this item at:
http://gna.org/bugs/?21798
___
Nachricht
Update of bug #15948 (project wesnoth):
Status: Ready For Test = Fixed
___
Reply to this item at:
http://gna.org/bugs/?15948
___
Nachricht
Update of bug #8106 (project wesnoth):
Status: Ready For Test = Fixed
___
Reply to this item at:
http://gna.org/bugs/?8106
___
Nachricht
Update of bug #22173 (project wesnoth):
Category: Bug = Feature Request
Status:None = Wont Fix
Open/Closed:Open = Closed
Update of bug #3856 (project wesnoth):
Status: Ready For Test = Fixed
___
Reply to this item at:
http://gna.org/bugs/?3856
___
Nachricht
Follow-up Comment #3, bug #22921 (project wesnoth):
My msvc build on master didn't reproduce it, i still get the game game called
Daniel's game and Sulla's ruins.
Note that boost locale s implementation might differ very much on different
os.
What i did get however is that my system default
Update of bug #22921 (project wesnoth):
Severity: 3 - Normal = 4 - Important
___
Reply to this item at:
http://gna.org/bugs/?22921
___
Nachricht
Update of bug #11618 (project wesnoth):
Status:None = Ready For Test
___
Follow-up Comment #1:
maybe fixed in https://github.com/wesnoth/wesnoth/pull/279
Update of bug #22897 (project wesnoth):
Item Group: None of the others = User Interface
___
Reply to this item at:
http://gna.org/bugs/?22897
___
Nachricht
Update of bug #22897 (project wesnoth):
Item Group: User Interface = None of the others
___
Reply to this item at:
http://gna.org/bugs/?22897
___
Nachricht
Update of bug #22891 (project wesnoth):
Item Group: None of the others = User Interface
___
Reply to this item at:
http://gna.org/bugs/?22891
___
Nachricht
Update of bug #22890 (project wesnoth):
Item Group: None of the others = Multiplayer
___
Reply to this item at:
http://gna.org/bugs/?22890
___
Nachricht
Update of bug #22890 (project wesnoth):
Status: Ready For Test = Need Info
___
Reply to this item at:
http://gna.org/bugs/?22890
___
Nachricht
Update of bug #22890 (project wesnoth):
Status:None = Ready For Test
Open/Closed:Open = Closed
___
Follow-up Comment #1:
i just tested again
Update of bug #22881 (project wesnoth):
Status:None = Ready For Test
___
Follow-up Comment #5:
now also backported to 1.12 marking as ready to test
URL:
http://gna.org/bugs/?22890
Summary: cannot select modifications for LoW Mp campaign
Project: Battle for Wesnoth
Submitted by: gfgtdf
Submitted on: Do 30 Okt 2014 00:25:39 UTC
Category: Bug
Severity: 3
Follow-up Comment #1, bug #22881 (project wesnoth):
this seems to be a bug on the c++ side rather then in Low (although it could
be solved by Low in a workaround too ofc).
I tihnk the reason is that extract_preload_scripts which extracts toplevel
[lua] scripts (like the one that defines
Follow-up Comment #2, bug #22881 (project wesnoth):
or maybe it's a resources::lua_kernel-initialize(); call that is missing?
unfortualtely i cannot test that since Low seems to be quite broken on master.
___
Reply to this item at:
Follow-up Comment #3, bug #22881 (project wesnoth):
no i think i got it all wrong. I now think that the time over event doesn't
fire in replays and that's why the replace_map etc doesnt even happen.
___
Reply to this item at:
Follow-up Comment #4, bug #22881 (project wesnoth):
fixed in master in
https://github.com/wesnoth/wesnoth/commit/52fb0597273f5cfd1783436a623e1eb6038b756f
___
Reply to this item at:
http://gna.org/bugs/?22881
Update of bug #22546 (project wesnoth):
Severity: 5 - Blocker = 3 - Normal
___
Follow-up Comment #6:
i had problmes with your commit when advancing to the next scenario after
reloading an old start
Update of bug #22147 (project wesnoth):
Assigned to:None = gfgtdf
___
Follow-up Comment #4:
backported commit in
Follow-up Comment #10, bug #21903 (project wesnoth):
for the log:
1.12 commit is:
https://github.com/wesnoth/wesnoth/commit/986002b44880093e848e7c10a8a08581d53e3796
master commit is:
https://github.com/wesnoth/wesnoth/commit/35f781d428aed486752d65d01624d9a236a363d5
Update of bug #20322 (project wesnoth):
Status: Ready For Test = Fixed
Assigned to:None = gfgtdf
___
Follow-up Comment #7:
assuming to be
Follow-up Comment #2, bug #21798 (project wesnoth):
becasue there is no answer it'll be assumed to be fixed on master and
nonexistent on 1.12.
___
Reply to this item at:
http://gna.org/bugs/?21798
Follow-up Comment #7, bug #22601 (project wesnoth):
pr is merged in 1.12 still needs to be done for 1.13
___
Reply to this item at:
http://gna.org/bugs/?22601
___
Nachricht gesendet
Update of bug #22643 (project wesnoth):
Assigned to:None = mattsc
___
Follow-up Comment #1:
unfortunateley i see no linenumbers in your errorreport (i guess thatÄs
normal for
Follow-up Comment #3, bug #22620 (project wesnoth):
Sp campaigns shouldn't be accessible via multiplayer because [campaign]type=
defaults to sp which means they aren't accesible via mp.
I also don't see how conflicts with imagefiles could appear. As soon as the sp
campaign starts the configs are
URL:
http://gna.org/bugs/?22635
Summary: mousemove event.
Project: Battle for Wesnoth
Submitted by: gfgtdf
Submitted on: So 14 Sep 2014 18:11:47 UTC
Category: Feature Request
Severity: 3 - Normal
Follow-up Comment #1, bug #22620 (project wesnoth):
and why is this harmful? Note that reloadoing might take some time so it's
desirable not to do it if it's not needed.
for [campaign]s we have the type=sp/mp/hybrid which specifies when a
campaigns should be accesible.
Update of bug #22546 (project wesnoth):
Severity: 4 - Important = 5 - Blocker
___
Follow-up Comment #2:
upgraded to blocker, start-of-scenario saves are the saves that are usualy
used when changing
Update of bug #22547 (project wesnoth):
Severity: 4 - Important = 5 - Blocker
___
Follow-up Comment #1:
upgraded to blocker, note that this is 1.13.0-dev so it doesn't block the
1.11.x releses.
Update of bug #22539 (project wesnoth):
Status:None = Fixed
___
Follow-up Comment #5:
the assertion was removed and the the [multiplayer] beeing present in sp saves
is part of
URL:
http://gna.org/bugs/?22546
Summary: wesnoth cannot load old start-of-scenario saves
Project: Battle for Wesnoth
Submitted by: gfgtdf
Submitted on: Do 28 Aug 2014 19:05:27 UTC
Category: Bug
Severity: 4
Update of bug #22546 (project wesnoth):
Assigned to: rhuvaen = riftwalker
___
Follow-up Comment #1:
misslicked. ofc it was meant to be assigned to riftwalker.
URL:
http://gna.org/bugs/?22516
Summary: [standard_unit_filter] id = behaviour changed
Project: Battle for Wesnoth
Submitted by: gfgtdf
Submitted on: So 24 Aug 2014 19:05:51 UTC
Category: Bug
Severity: 3
Follow-up Comment #10, bug #20719 (project wesnoth):
I think we should add name= also to the things that get preserved from
[scenario]. Especialy for the filenames of start-of-scenario saves this makes
sense because i think it would be nice if those were saved before the scenario
is generated.
Update of bug #19653 (project wesnoth):
Status:None = Fixed
___
Follow-up Comment #2:
see https://github.com/wesnoth/wesnoth/pull/265
Update of bug #20941 (project wesnoth):
Status:None = Wont Fix
___
Reply to this item at:
http://gna.org/bugs/?20941
___
Nachricht
Update of bug #22480 (project wesnoth):
Assigned to:None = riftwalker
___
Follow-up Comment #1:
This is annoying because:
1) we see information about other sides that we don't want to see
Update of bug #22410 (project wesnoth):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #1:
assuming as fixed bc
Update of bug #21962 (project wesnoth):
Status: Ready For Test = Fixed
___
Reply to this item at:
http://gna.org/bugs/?21962
___
Nachricht
Update of bug #21464 (project wesnoth):
Status:None = Fixed
___
Reply to this item at:
http://gna.org/bugs/?21464
___
Nachricht
Update of bug #18559 (project wesnoth):
Status:None = Fixed
Assigned to: upthorn = None
___
Reply to this item at:
Update of bug #13274 (project wesnoth):
Status:None = Fixed
___
Reply to this item at:
http://gna.org/bugs/?13274
___
Nachricht
Update of bug #14232 (project wesnoth):
Status:None = Need Info
___
Reply to this item at:
http://gna.org/bugs/?14232
___
Nachricht
Update of bug #22410 (project wesnoth):
Status:None = Ready For Test
___
Reply to this item at:
http://gna.org/bugs/?22410
___
Nachricht
Update of bug #22361 (project wesnoth):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #21866 (project wesnoth):
Status: Ready For Test = Fixed
___
Reply to this item at:
http://gna.org/bugs/?21866
___
Nachricht
Update of bug #20257 (project wesnoth):
Status:Wont Fix = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #6:
the code has changed
Update of bug #22305 (project wesnoth):
Open/Closed:Open = Closed
___
Reply to this item at:
http://gna.org/bugs/?22305
___
Nachricht
Update of bug #22268 (project wesnoth):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Follow-up Comment #2, bug #21565 (project wesnoth):
I do not have this bug (in 1.13-dev).
I do have a similar bug (resizing doesnt work during storyscreen) but that's
not related to how i rezize
I do also (in 1.13-dev) have a similar bug that when a rezize the window by
gragging to the
URL:
http://gna.org/bugs/?22305
Summary: assertion failure in unit map
Project: Battle for Wesnoth
Submitted by: gfgtdf
Submitted on: Do 10 Jul 2014 22:57:12 UTC
Category: Bug
Severity: 3 - Normal
Follow-up Comment #1, bug #22305 (project wesnoth):
ignore the '' character which caused quoting highlighting in teh previous
post.
___
Reply to this item at:
http://gna.org/bugs/?22305
___
Update of bug #22268 (project wesnoth):
Status:None = Ready For Test
___
Follow-up Comment #1:
ready for test
URL:
http://gna.org/bugs/?22263
Summary: inspect doesnt show variables if first is empty
Project: Battle for Wesnoth
Submitted by: gfgtdf
Submitted on: Do 03 Jul 2014 00:52:16 UTC
Category: Bug
Severity: 3
Update of bug #21884 (project wesnoth):
Severity: 3 - Normal = 2 - Minor
Priority: 5 - Normal = 2
___
Follow-up Comment #4:
Ok i think
Update of bug #22205 (project wesnoth):
Status:None = Invalid
Open/Closed:Open = Closed
___
Follow-up Comment #2:
closed since if i
Update of bug #21884 (project wesnoth):
Status: Invalid = None
Open/Closed: Closed = Open
___
Follow-up Comment #3:
i can reproduce this
Follow-up Comment #1, bug #22205 (project wesnoth):
if i remember correctly this is the intened behaviour:
During enter_hex, leave_hex the [allow_undo] has a special meaning which is
[not_stop_the_unit]. Note that this means enter_hex events doesn't prevent
undoing, if you want prevent undoing
Update of bug #22173 (project wesnoth):
Severity: 3 - Normal = 4 - Important
___
Follow-up Comment #1:
this bug annoys me so much.. i upgraded its importance.
But note this this ismmost likley only
Follow-up Comment #7, bug #22068 (project wesnoth):
ok i think my plan that, among other, also is intended to fix this bug (only
on master) (https://github.com/wesnoth/wesnoth/pull/201) is 77% finished.
___
Reply to this item at:
URL:
http://gna.org/bugs/?22173
Summary: check_victory broken inside draw.
Project: Battle for Wesnoth
Submitted by: gfgtdf
Submitted on: Di 10 Jun 2014 18:45:01 UTC
Category: Bug
Severity: 3 - Normal
Update of bug #22162 (project wesnoth):
Status:None = Confirmed
___
Follow-up Comment #1:
i noticed this too.
___
Reply to this
Follow-up Comment #3, bug #22046 (project wesnoth):
___
Reply to this item at:
http://gna.org/bugs/?22046
___
Nachricht gesendet von/durch Gna!
http://gna.org/
Follow-up Comment #4, bug #22046 (project wesnoth):
I dont have the original code which gave me the original error. I tried to
reproduce the error with the following code:
(place the start event in any scenario.)
[event]
name= start
[lua]
Follow-up Comment #21, bug #21966 (project wesnoth):
Yes those lines look correct.
i dont know exactly how this was handled in in 1.10.x but in 1.11.13+ not
executing the complete move if it was stopped by any reason is exactly the
expected behaviour.
(The following is molst likely not true for
Update of bug #22147 (project wesnoth):
Status:None = Ready For Test
___
Reply to this item at:
http://gna.org/bugs/?22147
___
Nachricht
Update of bug #21865 (project wesnoth):
Status:None = Fixed
___
Follow-up Comment #7:
i like when things can be marked as fixed.
Follow-up Comment #2, bug #22147 (project wesnoth):
ok i commited e3f7f2bcbc64a679f780919ebaf0ef9de775a1a3 to master which should
fix.
___
Reply to this item at:
http://gna.org/bugs/?22147
Follow-up Comment #1, bug #22144 (project wesnoth):
might be related to http://gna.org/bugs/?22046 where i get the same assertion
failure.
___
Reply to this item at:
http://gna.org/bugs/?22144
Follow-up Comment #5, bug #22068 (project wesnoth):
I currently have a plan that might (meaning it is not sure) fix this bug, but
that's a 1.13-only plan that won't get backported.
___
Reply to this item at:
http://gna.org/bugs/?22068
Update of bug #20257 (project wesnoth):
Status: Ready For Test = Wont Fix
___
Follow-up Comment #5:
ok in 1.13 the turn_info object is destroyed less often.
Update of bug #21983 (project wesnoth):
Assigned to:None = fendrin
___
Follow-up Comment #2:
i was told that fabi is the one to edit teh default hotkeys preferences file.
So i assigned this
Update of bug #21966 (project wesnoth):
Status:None = Need Info
___
Follow-up Comment #5:
well the reason seems to be that somewhere an impossible move was issured.
Which usualy causes
Update of bug #22073 (project wesnoth):
Assigned to:None = fendrin
___
Reply to this item at:
http://gna.org/bugs/?22073
___
Nachricht
Follow-up Comment #5, bug #21801 (project wesnoth):
i have investigated this problem on current master and it seems like the
slowness is mainly caused by the code that calculates the preview-maps in the
mp crate screen, especialy becasue we parse the [terrain_info] configs from
the game config
Follow-up Comment #1, bug #21983 (project wesnoth):
the
[hotkey]
command=editor-map-new
ctrl=yes
key=n
[/hotkey]
[hotkey]
command=editor-refresh
ctrl=yes
key=e
[/hotkey]
is most likeley a bug in wesnoths default hotkeys, (ctrl+e, ctrl+n beeing
applied to multiple actions with overlapping
URL:
http://gna.org/bugs/?22064
Summary: [hides][filter_delf][filter_vision] crashes wenoth
Project: Battle for Wesnoth
Submitted by: gfgtdf
Submitted on: Di 20 Mai 2014 22:57:25 UTC
Category: Bug
Update of bug #22064 (project wesnoth):
Summary: [hides][filter_delf][filter_vision] crashes wenoth
= [hides][filter_self][filter_vision] crashes wenoth
___
Reply to this item at:
http://gna.org/bugs/?22064
URL:
http://gna.org/bugs/?22046
Summary: Error when selectiong small gui elements
Project: Battle for Wesnoth
Submitted by: gfgtdf
Submitted on: Sa 17 Mai 2014 19:47:15 UTC
Category: Bug
Severity: 3 -
Update of bug #22046 (project wesnoth):
Summary: Error when selectiong small gui elements = Error
when selecting small gui elements
___
Reply to this item at:
http://gna.org/bugs/?22046
Follow-up Comment #1, bug #22045 (project wesnoth):
hm you could test what exactly the effect is, for example with an image like
http://i.imgur.com/LeVE9gN.png.
Also it could be helpful to know which verion of SDL you use for compiling,
and also what type of processor you have.
A fast look in
Follow-up Comment #6, bug #21882 (project wesnoth):
A) I consider this system to be natural: The presence of leaders is checked
if and only if a unit is killed in a combat.
Reason: any other kill of a leader is fully controled by a WML/lua coder,
and he can decide himself whether he wants to
Update of bug #21985 (project wesnoth):
Status:None = Fixed
___
Follow-up Comment #2:
now pushed to master too
___
Reply to
Update of bug #21986 (project wesnoth):
Status:None = Fixed
___
Follow-up Comment #6:
now pushed to master too
___
Reply to
Update of bug #20826 (project wesnoth):
Status: Ready For Test = None
___
Reply to this item at:
http://gna.org/bugs/?20826
___
Nachricht
Update of bug #20826 (project wesnoth):
Status:None = Ready For Test
Assigned to: gfgtdf = None
___
Follow-up Comment #6:
accidently changed
Follow-up Comment #1, bug #21985 (project wesnoth):
fixed in 1.12 in 555ac3396da5b16e8f640b55783fe85b7d68609d
___
Reply to this item at:
http://gna.org/bugs/?21985
___
Nachricht gesendet
Follow-up Comment #5, bug #21986 (project wesnoth):
fixed in 1.12 in d1b3cd13e85188722269d7043f4394843cd911c9
___
Reply to this item at:
http://gna.org/bugs/?21986
___
Nachricht gesendet
Update of bug #21986 (project wesnoth):
Assigned to:None = gfgtdf
___
Reply to this item at:
http://gna.org/bugs/?21986
___
Nachricht
Update of bug #21985 (project wesnoth):
Assigned to:None = gfgtdf
___
Reply to this item at:
http://gna.org/bugs/?21985
___
Nachricht
Update of bug #21961 (project wesnoth):
Status:None = Fixed
___
Follow-up Comment #3:
fixed on 1.12 + master
701 - 800 of 992 matches
Mail list logo
