[Wesnoth-bugs] [bug #25679] -t parameter for wesnoth executable

2017-04-27 Thread Severin Glöckner
URL:
  

 Summary: -t parameter for wesnoth executable
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Do 27 Apr 2017 18:26:46 CEST
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.7+dev
Operating System: Linux

___

Details:

While I wanted to add a manpage entry for -tmicro_ai_test I realized it's
actually only making use of the -t option. But either -t is not documented
correctly or not implemented correctly.


Small extract from the manpage:

-t, --test [scenario_id]
runs  the game in a small test scenario. The scenario should be one defined
with a [test] WML tag. The default is "test". Implies --nogui.


So, wesnoth -t starts the default test scenario.
wesnoth -t test should be the same, but actually it's wesnoth -ttest
Long option mode isn't working either way, only without arguments.


Since usually there is a space between the option and the argument and long
option mode isn't working with arguments I'd argue to change rather that than
the documentation.




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25665] Preferences window has scrollbars in German language (independent from resolution)

2017-04-17 Thread Severin Glöckner
URL:
  

 Summary: Preferences window has scrollbars in German language
(independent from resolution)
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Mo 17 Apr 2017 21:16:22 CEST
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.7+dev
Operating System: Archlinux

___

Details:





___

File Attachments:


---
Date: Mo 17 Apr 2017 21:16:23 CEST  Name: high_res.jpg  Size: 550kB   By:
shiki



___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25660] linear scaling option - artefacts for red ellipses, while blue ones are fine

2017-04-17 Thread Severin Glöckner
Follow-up Comment #2, bug #25660 (project wesnoth):

Oh, now I understand what the comments there meant.

Maybe it's time to fix that one, I heard a few times of bugs which could be or
are related to that one.

Personally I liked the xbrz+linear option more. (or was it just linear)


___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25664] debug: redraw issue with unit placement window

2017-04-17 Thread Severin Glöckner
Follow-up Comment #2, bug #25664 (project wesnoth):

fixed, thanks

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25664] debug: redraw issue with unit placement window

2017-04-16 Thread Severin Glöckner
URL:
  

 Summary: debug: redraw issue with unit placement window
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: So 16 Apr 2017 22:45:29 CEST
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.7+dev
Operating System: Archlinux

___

Details:

In a few seldom cases the window for unit placement is becoming wider. It can
shrink afterwards again.
In that case a redraw is missing (see picture)

I don't have a concrete example yet which widens the window nor why it is
necessary...

What works for reproduction:
with german locale, search for >wal< (Waldschrat, wose)
delete the last letter, so it's just >wa<
The window's width shrinked.

search for >kü<   (Kürassier)
delete the last letter, so it's just >K>
The window's width just became wider.

I have in the list the units from default and Era of Myths, for the case that
it makes a difference.

minimize redraws redraws the screen.




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25660] linear scaling option - artefacts for red ellipses, while blue ones are fine

2017-04-15 Thread Severin Glöckner
URL:
  

 Summary: linear scaling option - artefacts for red ellipses,
while blue ones are fine
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Sa 15 Apr 2017 11:50:08 CEST
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.7+dev
Operating System: Archlinux

___

Details:

Have a look at the picture. The game is scaled up with, it think it was ctrl +
´.
While the blue ellipses are looking fine, there are strange pixels appearing
on the red ones.

Same for xbrz+linear option.
Disabling ellipses doesn't show the pixels anymore.
The strange thing is, it only happens for the red ellipses, not the blue.




___

File Attachments:


---
Date: Sa 15 Apr 2017 11:50:08 CEST  Name: red_circles.png  Size: 454kB   By:
shiki



___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25643] larger window for paths listing

2017-04-10 Thread Severin Glöckner
URL:
  

 Summary: larger window for paths listing
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Mo 10 Apr 2017 17:55:42 CEST
Category: Feature Request
Severity: 4 - Important
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.7+dev
Operating System: Linux

___

Details:

The window which appears when clicking the [i] on the titlescreen could be a
bit wider. With the current length I assume that most paths won't be displayed
fully.
A path length like this should be displayed without shortening:
/home/username/.local/share/wesnoth/1.13/data/add-ons/

Shortening the paths for the standard locations doesn't make sense, this
windows exists to make things easier, not complicated.





___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25642] path of the executable - listing it as well in the paths list

2017-04-10 Thread Severin Glöckner
URL:
  

 Summary: path of the executable - listing it as well in the
paths list
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Mo 10 Apr 2017 17:48:36 CEST
Category: Feature Request
Severity: 1 - Wish
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.7+dev
Operating System: Linux

___

Details:

I think the path to the executable should be listed as well in the list of
locations which is available at the [i] on the titlescreen. Many Linux
distributions use different locations for it.
Eventually we could only show this if it differs from the game data directory,
since it's for windows not of interest.




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25013] weapon naming: with or without space?

2017-03-23 Thread Severin Glöckner
Follow-up Comment #7, bug #25013 (project wesnoth):

It's easy to miss a discussion 

All other are in, but for morning star/morningstar I left it, since I didn't
know which to choose.

It's morningstar in the Hammer of Thursagan
and morning star in core / everywhere else.

Though some attacks names changed to flail, or maces to morningstars.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25013] weapon naming: with or without space?

2017-03-23 Thread Severin Glöckner
Follow-up Comment #5, bug #25013 (project wesnoth):

Actually implemented with https://github.com/wesnoth/wesnoth/pull/915

Though there's still the difference between morningstar and morning star left.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25623] Redraw issue when switching from/to fullscreen

2017-03-23 Thread Severin Glöckner
Follow-up Comment #2, bug #25623 (project wesnoth):

With ctrl+F everything works fine, never used this before.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25622] Minimap reveals shroud prematurely

2017-03-23 Thread Severin Glöckner
Follow-up Comment #4, bug #25622 (project wesnoth):

It's the other way around, she can move more than she can see.
For the unit_type exists the movement key and the vision key. By default that
is the same, I doubt that really somebody is using the vision key. In this
case I gave her more moves with debug mode.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25624] help:

2017-03-23 Thread Severin Glöckner
Follow-up Comment #1, bug #25624 (project wesnoth):

help & [variation]s: effect of the hide_help key

Imagine you have one unit with one variation. Like Konrad in HttT.
And imagine you don't use inherit=yes (unlike the zombies), not sure if that
would make a difference.

Currently Konrad and Li'sar use hide_help=yes for the variation, and not for
the main unit.
This has three effects
  -> 1) the variation is not shown in the help browser
  -> 2) the variation is not shown in the main units wiki page. There would
usually be a line "variations:"
  -> 3) when the variation is in effect, e.g. Konrad has the sceptre, it shows
the page of the main unit instead of the variation.
This is different than in the usual cases where hide_help=yes it used. As a
rule of thumb, hide_help=yes does hide the unit in the help system, but there
exists still a help page which is only accessible if the unit is on the
field.
tl;dr, Konrads Sceptre attack isn't displayed in the help when he has it.

Why did the designer decide for that? We'll, let's have a look at the other
options:

Using hide_help=yes for both:
  -> they are both not accessible in the help browser. That's mostly fine for
heroes.
  -> the main unit's help page is still accessible on the map, the variation
has still the same problem as before

Using hide_help=no for both:
  -> the variation's help entry can now be accessed over the map, but also
over the help and
  -> due to the "variations:" line in the main units help entry this would
spoil the player

For completeness sake (or rather, to show another issue)
Using hide_help=yes only for the main unit:
  -> Isn't useful here
  -> the variation has usually a link to the base unit. That link is now
displayed in red and broken. It should just not be displayed


TL;DR (again)
I think things would be better
  -> if variations with hide_help=yes would have an help entry which is only
accessible over the map (like for unit_types)
  -> if the link to the main unit is not shown when the main unit uses
hide_help=yes

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25624] help:

2017-03-23 Thread Severin Glöckner
URL:
  

 Summary: help:
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Fr 24 Mär 2017 02:30:47 UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.7+dev
Operating System: Archlinux

___

Details:






___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25622] Minimap

2017-03-23 Thread Severin Glöckner
Follow-up Comment #2, bug #25622 (project wesnoth):

Note: The unit has to be selected for this.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25622] Minimap

2017-03-23 Thread Severin Glöckner
Follow-up Comment #1, bug #25622 (project wesnoth):

When a unit has more movement points than vision points, it is showing the
shrouded area on the minimap too.

I think it is good that it's not revealing the shroud, but the minimap
shouldn't do so either.



I submitted this to early, can someone adjust change the title?

(file #29900)
___

Additional Item Attachment:

File name: minimap.pngSize:582 KB


___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25622] Minimap

2017-03-23 Thread Severin Glöckner
URL:
  

 Summary: Minimap 
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Fr 24 Mär 2017 00:58:30 UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.12 / 1.13.7+dev
Operating System: Archlinux

___

Details:






___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25621] hotkey preferences: add a hotkey which needs shift

2017-03-23 Thread Severin Glöckner
Follow-up Comment #2, bug #25621 (project wesnoth):

yes, the preferences file.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25321] choose-game-to-load-screen with very long scenario name

2017-03-17 Thread Severin Glöckner
Follow-up Comment #12, bug #25321 (project wesnoth):

made no difference

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25321] choose-game-to-load-screen with very long scenario name

2017-03-17 Thread Severin Glöckner
Follow-up Comment #11, bug #25321 (project wesnoth):

building with scons

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25321] choose-game-to-load-screen with very long scenario name

2017-03-17 Thread Severin Glöckner
Follow-up Comment #10, bug #25321 (project wesnoth):

Some time ago I used clang with ccache, but I think it's been a while - I'll
try a clean build. 

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25321] choose-game-to-load-screen with very long scenario name

2017-03-17 Thread Severin Glöckner
Follow-up Comment #8, bug #25321 (project wesnoth):

building with gcc 6.3

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25321] choose-game-to-load-screen with very long scenario name

2017-03-17 Thread Severin Glöckner
Follow-up Comment #5, bug #25321 (project wesnoth):

There is a comment in the po file mentioning that place, more I don't know
about it. Where does Thursday come from?

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25321] choose-game-to-load-screen with very long scenario name

2017-03-17 Thread Severin Glöckner
Follow-up Comment #3, bug #25321 (project wesnoth):

I managed to get a scroll-bar with
"The Journey BeginsX"
but longer titles, like a sentence without spaces (as well as with) went
fine.

About Thursday I can't test, it's not shown as translated anymore in German.
And grepping (with -i) for "thursday" did only reveal po & mo files, it's not
appearing in the a few commit earlier generated pot file, nor in code files.
Earlier it seems to have been at src/strftime.cpp:26, this files doesn't exist
anymore. (Some new bug about translatability here it seems)

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25604] Shuffle Sides Recruit list bug

2017-03-17 Thread Severin Glöckner
Follow-up Comment #3, bug #25604 (project wesnoth):

Now that you say it, I had this bug too, and couldn't figure out what I messed
up, forgot about that when I deleted the config.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25592] Do not reset the zooming level each time a game is loaded

2017-03-13 Thread Severin Glöckner
URL:
  

 Summary: Do not reset the zooming level each time a game is
loaded
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Di 14 Mär 2017 02:33:55 UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Linux

___

Details:

When zooming with "+" the change is not persistent, it would be better if the
value is saved.




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25591] Setting the map scaling with the mouse

2017-03-13 Thread Severin Glöckner
URL:
  

 Summary: Setting the map scaling with the mouse
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Di 14 Mär 2017 02:31:43 UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Linux

___

Details:

There is the magnifying glass icon on the minimap to disable or enable zooming
of the main map. An possibility for setting the zooming level or different
zooming strengths would be good there too. 
(when I first tried out the icons under the minimap I didn't find much use of
the magnifying icon - in my case it actually zoomed out a lot)




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25561] stderr message about unescaped

2017-03-13 Thread Severin Glöckner
Follow-up Comment #5, bug #25561 (project wesnoth):

It's all, scenario description (like player 1&4 vs 2&3), add-on description
and author labels.

I think it's fine to allow &, and for the end users this messages are then
looking like the author has to do sth. about it, be it a warning or an error.
Though warning sounds better than error ;)

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25558] lua error with micro ai

2017-03-13 Thread Severin Glöckner
Follow-up Comment #8, bug #25558 (project wesnoth):

fixed

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25587] Error message about another (unrelated) add-on when starting a campaign & sth goes wrong with sourcing.

2017-03-13 Thread Severin Glöckner
Follow-up Comment #2, bug #25587 (project wesnoth):

> Just to be sure, you are taking about restarting wesnoth not about just
ending the campaign/going back to main menu right?

Yes, talking about that.

Well, I think that's a bug with which we can live.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25585] segfault when clicking on the "x" while the application launches.

2017-03-11 Thread Severin Glöckner
URL:
  

 Summary: segfault when clicking on the "x" while the
application launches.
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Sat 11 Mar 2017 07:03:45 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Debian 8

___

Details:

When closing the application while it still starts it segfaults.

I can't provide a back/stack strace right now because gdb segfaults too then I
start it with "gdb wesnoth/wesnoth-debug" while reading the debugging
symbols... which is a bit odd..

Can someone confirm this?

I made a clean build, and removed the ccache before too.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25558] lua error with micro ai

2017-03-10 Thread Severin Glöckner
Follow-up Comment #6, bug #25558 (project wesnoth):

I'm not sure if I can try it still out today, left my laptop at work and have
atm just a library PC, but I let you know when I can.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25558] lua error with micro ai

2017-03-10 Thread Severin Glöckner
Follow-up Comment #3, bug #25558 (project wesnoth):

You can use this for testing:
git clone https://github.com/sevu/WotD War_of_the_Dragon
and then :cl to the seventh scenario

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25558] lua error with micro ai

2017-03-10 Thread Severin Glöckner
Follow-up Comment #2, bug #25558 (project wesnoth):

unfortunately not

message is the same as before

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25584] some dialogs windows on titlescreen stop working when resizing the game window

2017-03-09 Thread Severin Glöckner
URL:
  

 Summary: some dialogs windows on titlescreen stop working
when resizing the game window
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Do 09 Mär 2017 23:45:06 UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

Maximizing or resizing the window when the the
a) multiplayer window which asks you what kind of multiplayer you want
b)the campaign selection screen
c)the difficulty selection afterwards
results that the game in the end returns to the titlescreen.

In case b) I get the difficulty selection afterwards and then shows the
loading screen, but it returns to the titlescreen then too.

Settings, language settings and add-on server dialogs are not affected.




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25568] resizing window in team selection screen

2017-03-09 Thread Severin Glöckner
Follow-up Comment #2, bug #25568 (project wesnoth):

I'm building every few days, probably it was. Made today a clean build, it
didn't change.
Take a 5p game. I have a 1920x1080 screen and had the window set to 1368x768.
I also noted that if I start the same game from the beginning maximized, there
is no scrollbar and the chat below is smaller.
While if it's started in the smaller window and maximized when I did not
scroll down I do have s scrollbar (while it almost would fit without)



(file #29877)
___

Additional Item Attachment:

File name: bug_5p.png Size:338 KB


___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25569] touchpad scrooling in team selection screen

2017-03-09 Thread Severin Glöckner
Follow-up Comment #2, bug #25569 (project wesnoth):

I never noticed o.O
Seems to be only empty locations where it doesn't work, and if there's a short
moment in between arriving at the location and scrolling.
What is maybe related, when you are before scrolling with the mouse over a
box, and scroll down with the mouse wheel, the old one is still highlighted.

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25569] touchpad scrooling in team selection screen

2017-03-07 Thread Severin Glöckner
URL:
  

 Summary: touchpad scrooling in team selection screen
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Di 07 Mär 2017 23:54:20 UTC
Category: Feature Request
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group: Multiplayer Lobby
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

Could scrolling the players list with the touchpad be enabled for the upper
left part?
That exists already in the new add-on manager.




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25568] resizing window in team selection screen

2017-03-07 Thread Severin Glöckner
URL:
  

 Summary: resizing window in team selection screen
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Di 07 Mär 2017 23:48:19 UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer Lobby
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

When the list of players is longer and you have a scrollbar for it, scroll
down and then maximize the window. After that you can't scroll up anymore.





___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25560] players get moved to the end of the list, if they choose their current team again

2017-03-07 Thread Severin Glöckner
Follow-up Comment #2, bug #25560 (project wesnoth):

confiremd, thanks

___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25561] stderr message about unescaped

2017-03-05 Thread Severin Glöckner
URL:
  

 Summary: stderr message about unescaped &
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: So 05 Mär 2017 15:40:32 UTC
Category: Feature Request
Severity: 1 - Wish
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Linux

___

Details:

In map descriptions, the author field in the add-on manager or similar cases
like that n "&" is used, there is a message like that drooped on stderr:

20170305 16:30:36 error gui/layout: pango_text::set_markup_helper text 'Eagle
11 & Dugi' has unescaped ampersands '&', escaped them.

I think it doesn't make sense to escape them in the _sever.pbl and scenario
files.
Maybe we can hide that message in stderr?




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25560] players get moved to the end of the list, if they choose their current team again

2017-03-05 Thread Severin Glöckner
URL:
  

 Summary: players get moved to the end of the list, if they
choose their current team again
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: So 05 Mär 2017 15:12:34 UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Multiplayer Lobby
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

In the 2nd Screen for creating am multiplayer match you can switch teams with
a drop-down box.
To better see what will happen, assign one side to AI, and select different
leaders for all players.

Assign multiple players to a team (can be all)

If you click on the drop box button, it opens the drop down list and let's you
select an team.
If you choose the team in which you currently are, you get moved to the end of
the players list for this team.

Probably it's in the code sth. like a remove and add to this team, like it
would be in the other cases.
But it shouldn't be like that, it's confusing. Because actually nothing should
happen.
Choosing your current team is for the player more like aborting the team
switching.





___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25558] lua error with micro ai

2017-03-04 Thread Severin Glöckner
URL:
  

 Summary: lua error with micro ai
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Sa 04 Mär 2017 21:54:20 UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:


20170304 22:43:46 error scripting/lua: lua/wml-tags.lua:744: bad argument #2
to 'sub' (number expected, got nil)
stack traceback:
[C]: in function 'string.sub'
lua/wml-tags.lua:744: in field '?'
lua/backwards-compatibility.lua:11: in field 'fire'
lua/helper.lua:244: in field 'modify_ai'
ai/micro_ais/micro_ai_helper.lua:96: in field 'add_CAs'
ai/micro_ais/micro_ai_helper.lua:218: in field 'micro_ai_setup'
ai/micro_ais/micro_ai_wml_tag.lua:51: in local 'cmd'
lua/wml-utils.lua:145: in field 'handle_event_commands'
lua/wml-flow.lua:6: in function 


the following code generates the above error in 1.13:


[event]
name=turn 2
[unit]
side=6
id=microai1
type=Giant Scorpion
x=10
y=10
[/unit]
[micro_ai]
side=6
ai_type=big_animals
action=add
[filter]
id=microai1
[/filter]
[/micro_ai]
[/event]





___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25496] HTTT: S18 - Is Delfador using the right portrait consistently?

2017-02-07 Thread Severin Glöckner
URL:
  

 Summary: HTTT: S18 - Is Delfador using the right portrait
consistently?
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Mi 08 Feb 2017 06:38:34 UTC
Category: Bug
Severity: 1 - Wish
Priority: 5 - Normal
  Item Group: Campaign
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

I jumped with debug mode to S18. In the dialog Delfador used the elvish
clothes, but the humans ones when he was using the "mentoring" image.
However, it probably may be the case that in an earlier scenario which I
skipped with debug mode the portrait of Delfador is changed for wearing human
clothes.

Now, playing 18 scenarios to verify that is maybe not the most efficient
way...




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25483] Segfault when using :inspect and selecting an event which has an id

2017-02-01 Thread Severin Glöckner
URL:
  

 Summary: Segfault when using :inspect and selecting an event
which has an id
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Do 02 Feb 2017 03:55:05 UTC
Category: Bug
Severity: 1 - Wish
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.12 only
Operating System: Archlinux

___

Details:

I did get this message on stderr:
20170202 01:25:04 error gui/general: vertical_scrollbar [_vertical_scrollbar]
recalculate: Can't recalculate size, force a window layout phase.
wesnoth: /build/wesnoth/src/wesnoth/src/gui/widgets/grid.cpp:529: virtual void
gui2::tgrid::place(const gui2::tpoint&, const gui2::tpoint&): Assertion
`false' failed.

That's this line in the code:
https://github.com/wesnoth/wesnoth/blob/1.12/src/gui/widgets/grid.cpp#L529
The comment states that this shouldn't be possible... and somehow it is.

We can only reach that place if this conditional fails:
https://github.com/wesnoth/wesnoth/blob/1.12/src/gui/widgets/grid.cpp#L466

As for 1.13, there have been some work on this function, and this conditional
is not there anymore. I guess it did get refactored away, since, as the
comment states, we shouldn't have been able to fail it anyway... but somehow
it did.

But there has been as well other work on that function.


Reproduction steps:
Download War_of_the_Dragon campaign from the add-on server. (currently
v1.4.2)
Start the campaign, switch to debug mode, use :cl to skip to the 6th scenario,
use :inspect, click on events and there on the one only one which has an ID.
I guess it's the case with other events with ids in mainline, but i didn't
find a test case.

stack and backtraces

Stack trace of thread 1572:
#0  0x7f3a3cf0104f raise (libc.so.6)
#1  0x7f3a3cf0247a abort (libc.so.6)
#2  0x7f3a3cef9ea7 __assert_fail_base (libc.so.6)
#3  0x7f3a3cef9f52 __assert_fail (libc.so.6)
#4  0x0077b349 _ZN4gui25tgrid5placeERKNS_6tpointES3_
(wesnoth)
#5  0x00728c2d
_ZN4gui211tcontainer_5placeERKNS_6tpointES3_ (wesnoth)
#6  0x0079c894
_ZN4gui220tscrollbar_container5placeERKNS_6tpointES3_ (wesnoth)
#7  0x007811dd
_ZN4gui28tlistbox5placeERKNS_6tpointES3_ (wesnoth)
#8  0x00775b43
_ZN4gui25tgrid6tchild5placeENS_6tpointES2_ (wesnoth)
#9  0x007775e6 _ZN4gui25tgrid6layoutERKNS_6tpointE
(wesnoth)
#10 0x0077a425 _ZN4gui25tgrid5placeERKNS_6tpointES3_
(wesnoth)
#11 0x00775b43
_ZN4gui25tgrid6tchild5placeENS_6tpointES2_ (wesnoth)
#12 0x007775e6 _ZN4gui25tgrid6layoutERKNS_6tpointE
(wesnoth)
#13 0x0077a425 _ZN4gui25tgrid5placeERKNS_6tpointES3_
(wesnoth)
#14 0x00775b43
_ZN4gui25tgrid6tchild5placeENS_6tpointES2_ (wesnoth)
#15 0x007775e6 _ZN4gui25tgrid6layoutERKNS_6tpointE
(wesnoth)
#16 0x0077a425 _ZN4gui25tgrid5placeERKNS_6tpointES3_
(wesnoth)
#17 0x00775b43
_ZN4gui25tgrid6tchild5placeENS_6tpointES2_ (wesnoth)
#18 0x007775e6 _ZN4gui25tgrid6layoutERKNS_6tpointE
(wesnoth)
#19 0x0077a425 _ZN4gui25tgrid5placeERKNS_6tpointES3_
(wesnoth)
#20 0x0079c92a
_ZN4gui220tscrollbar_container5placeERKNS_6tpointES3_ (wesnoth)
#21 0x00775b43
_ZN4gui25tgrid6tchild5placeENS_6tpointES2_ (wesnoth)
#22 0x007775e6 _ZN4gui25tgrid6layoutERKNS_6tpointE
(wesnoth)
#23 0x0077a425 _ZN4gui25tgrid5placeERKNS_6tpointES3_
(wesnoth)
#24 0x00728c2d
_ZN4gui211tcontainer_5placeERKNS_6tpointES3_ (wesnoth)
#25 0x007df395 _ZN4gui27twindow6layoutEv (wesnoth)
#26 0x007e0686 _ZN4gui27twindow4drawEv (wesnoth)
#27 0x00710618
_ZN4gui25event14implementation10fire_eventIN5boost8functionIFvRNS0_11tdispatcherENS0_6teventERbS8_EEENS0_8ttriggerEEEbS7_RSt6vectorISt4pairIPNS_7twidgetES7_ESaISG_EESF_SF_T0_
(wesnoth)
#28 0x0070d33b
_ZN4gui25event11tdispatcher4fireENS0_6teventERNS_7twidgetE (wesnoth)
#29 0x0071e141 _ZN4gui25event8thandler4drawEb
(wesnoth)
#30 0x0071f528
_ZN4gui25event8thandler12handle_eventERK9SDL_Event (wesnoth)
#31 0x00f1486c _ZN6events4pumpEv (wesnoth)
#32 

[Wesnoth-bugs] [bug #25465] Add-on server: switch to the simpler URLs

2017-01-23 Thread Severin Glöckner
URL:
  

 Summary: Add-on server: switch to the simpler URLs
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Mon 23 Jan 2017 02:25:25 PM UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13
Operating System: Linux

___

Details:

In the _server.pbl it's possible to add the thread_id of the forum thread, and
the game creates then the URL which is displayed in the add-on server.

The add-on server creates currently URLs like
http://forums.wesnoth.org/viewtopic.php?t=10231

But it could create instead an URL like 
https://r.wesnoth.org/t10231




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25455] Manpages, German translation missing & welcome 2017

2017-01-21 Thread Severin Glöckner
Follow-up Comment #5, bug #25455 (project wesnoth):

Makes sense. I could translate it for 1.13.8.

I think the file for translation can be obtained from gettext. wesnoth.org.
But how can I test/compile the translation myself?


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25456] Let version_suffix affect the manpage names too

2017-01-19 Thread Severin Glöckner
URL:
  

 Summary: Let version_suffix affect the manpage names too
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Fri 20 Jan 2017 12:30:28 AM UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

Currently, there is no way to have both 1.12 and 1.13 in parallel installed
and have access to the manpages of both versions.
While the mandir option (for scons) can be used to have the manpages of both
versions installed without collision, it's not possible to access both.

For scons, can the value of program_suffix be added to the filenames of the
manpages too? Since the manpages are for the commands which are affected by
this option.
When program_suffix would affect that, version_suffix should do that to.

However, in the manpage itsef, the command will still be named without version
suffix, but I think that's the better compromise.


It may help the people who make the translation if both manpages are
accessible.


For cmake, it seems there is the BINARY_SUFFIX option (and no equivalent to
version_suffix)




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25455] Manpages, German translation missing & welcome 2017

2017-01-19 Thread Severin Glöckner
Follow-up Comment #1, bug #25455 (project wesnoth):

Actually it is missing for every language besides en_GB, it and gl.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25455] Manpages, German translation missing & welcome 2017

2017-01-19 Thread Severin Glöckner
URL:
  

 Summary: Manpages, German translation missing & welcome 2017
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Thu 19 Jan 2017 11:46:09 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

... and where did the german translation for 'wesnoth' go? only the one for
'wesnothd' is there (while in 1.12 both exist)

And since we have now 2017, the copyright notice can be updated.
There is one at the bottom and at the top (which was forgotten the last time)
of the files. 




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25389] swamp/water transition - use the correct water for it

2016-12-14 Thread Severin Glöckner
URL:
  

 Summary: swamp/water transition - use the correct water for
it
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Wed 14 Dec 2016 03:38:52 PM UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Graphics
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

Wesnoth has different types of water, it looks not all time the same.

In the transition between tropical water and swamp, it uses the wrong
(standard) water for the transition.
Which looks then as seen on the picture.



___

File Attachments:


---
Date: Wed 14 Dec 2016 03:38:52 PM UTC  Name: swampandwater.png  Size: 662kB  
By: shiki



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25376] resizing window when starting a campaign

2016-12-10 Thread Severin Glöckner
URL:
  

 Summary: resizing window when starting a campaign
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Sat 10 Dec 2016 09:10:30 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

Play in windowed mode.
Start a new campaign. After selecting the difficulty, when the loading screen
shows, doubleclick on the title bar to to resize the window.

In the case that the window is smaller afterwards, wesnoth shuts down (without
crash), and leaves this message in stderr:

WML exception:
User message: Anzeigen eines Dialogfensters fehlgeschlagen. Es passt nicht in
die aktuelle Fenstergröße.
Dev message: src/gui/widgets/window.cpp:1021 in function 'layout' found the
following problem: Failed to size window; wanted size 610,905 available size
1229,673 screen size 1229,673.

- if the window get's bigger , thats fine
- if the windows get's bigger and afterwards back to the old size, that works,
but the logo which is displayed during loading is now out of place
- disable_loadingscreen_animation=yes in the preference file has no influence
on this




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25374] Tutorial: situation where you can do nothing

2016-12-09 Thread Severin Glöckner
URL:
  

 Summary: Tutorial: situation where you can do nothing
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Sat 10 Dec 2016 02:06:59 AM UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Campaign
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

In turn three, if you do not follow the order from delfador to go to the keep
and recruit fighters, but attack instead again, you cannot end your turn
afterwards.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25370] Segmentation fault, possibly related to [animate_unit] with many [animate] subtags

2016-12-08 Thread Severin Glöckner
Follow-up Comment #4, bug #25370 (project wesnoth):

You can try the Ageless version from 1.12 or github. I seems it works until
1.13.6, but not on current master.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25361] scrollbar in advance dialog

2016-12-06 Thread Severin Glöckner
Follow-up Comment #3, bug #25361 (project wesnoth):

It affects as well the recruit dialog, Son of the Black-Eye may serve as
example.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25361] scrollbar in advance dialog

2016-12-06 Thread Severin Glöckner
Follow-up Comment #2, bug #25361 (project wesnoth):

The Ghost and Troll Whelp are examples in mainline.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25359] chill wave animation doesn't get played

2016-12-06 Thread Severin Glöckner
Follow-up Comment #3, bug #25359 (project wesnoth):

Just normal combat.

I guess Celtic Minstrel fixed it without even seeing this report.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25359] chill wave animation doesn't get played

2016-12-05 Thread Severin Glöckner
Follow-up Comment #1, bug #25359 (project wesnoth):

Fixed by
https://github.com/wesnoth/wesnoth/commit/597589fb1019829dfdeb0a3793a4fd94f6820d48

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25363] Dead Water, S2: The Chest

2016-12-05 Thread Severin Glöckner
URL:
  

 Summary: Dead Water, S2: The Chest
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Mon 05 Dec 2016 12:54:13 PM UTC
Category: Feature Request
Severity: 1 - Wish
Priority: 5 - Normal
  Item Group: Campaign
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

When you kill the leader in the east, you get as reward a bat and some gold.
There is a message telling you about it, and there get's this chest spawned.

But it confused me, I thought I have to pick up the chest to get something.
Like the ring from the leader in the south, you have to pick it up too. Or
like it is mostly in games if an item spawns.


PS: the portrait is only so small because of the small resolution.
PPS: In German the tent is translated as cave. 



___

File Attachments:


---
Date: Mon 05 Dec 2016 12:54:13 PM UTC  Name: chest.jpg  Size: 248kB   By:
shiki


---
Date: Mon 05 Dec 2016 12:54:13 PM UTC  Name: german.jpg  Size: 323kB   By:
shiki



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25321] choose-game-to-load-screen with very long scenario name

2016-12-05 Thread Severin Glöckner
Follow-up Comment #1, bug #25321 (project wesnoth):

There's one more case. If you want to load a game on Thursday.
Thursday is the longest weekname in German.

(file #29547)
___

Additional Item Attachment:

File name: long weekname.png  Size:813 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25361] scrollbar in advance dialog

2016-12-05 Thread Severin Glöckner
URL:
  

 Summary: scrollbar in advance dialog
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Mon 05 Dec 2016 10:43:27 AM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

The advance dialog has it's highness depending on the place which is needed
for displaying the first option.
If another option would need more place, we get a scrollbar.



___

File Attachments:


---
Date: Mon 05 Dec 2016 10:43:27 AM UTC  Name: long_list_is_2nd.jpg  Size: 378kB
  By: shiki


---
Date: Mon 05 Dec 2016 10:43:27 AM UTC  Name: long_list_is_1st.jpg  Size: 439kB
  By: shiki



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25360] variants in the ingame help

2016-12-05 Thread Severin Glöckner
URL:
  

 Summary: variants in the ingame help
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Mon 05 Dec 2016 09:56:47 AM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

Looks a bit strange right now.

The zombies WML didn't change in the recent time.





___

File Attachments:


---
Date: Mon 05 Dec 2016 09:56:47 AM UTC  Name: variants.png  Size: 47kB   By:
shiki



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25359] chill wave animation doesn't get played

2016-12-05 Thread Severin Glöckner
URL:
  

 Summary: chill wave animation doesn't get played
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Mon 05 Dec 2016 09:07:34 AM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

For whatever reason, the chill wave animation doesn't get played.
It seems that the [attack_anim] block is getting ignored.
Works for all other attacks.
And there is no message in stderr, it's not an image-not-found error.

The WML itself is fine, and had no changes for a while.





___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25348] segfault: killed a unit with debug mode, which should have triggered an event afterwards

2016-12-01 Thread Severin Glöckner
Follow-up Comment #4, bug #25348 (project wesnoth):

same here

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25348] segfault: killed a unit with debug mode, which should have triggered an event afterwards

2016-12-01 Thread Severin Glöckner
Follow-up Comment #2, bug #25348 (project wesnoth):

without that commit it doesn't crash

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25348] segfault: killed a unit with debug mode, which should have triggered an event afterwards

2016-11-30 Thread Severin Glöckner
URL:
  

 Summary: segfault: killed a unit with debug mode, which
should have triggered an event afterwards
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Thu 01 Dec 2016 12:53:01 AM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

I'm not finding a better title right now...
This happened in the 6th scenario of War_of_the_Dragon, where I killed one of
my leaders.
The other was stored in a variable.
The event would have been triggered if the first one is getting killed, it
wuld then have unstored the 2nd and ended the level. And this works if the
unit gets killed without the debug command.

Thats the stderr message:
wesnoth-git: src/units/map.hpp:177: pointer
unit_map::iterator_base::operator->() const
[iter_types = unit_map::standard_iter_types]: Assertion `valid()' failed.
Abgebrochen (Speicherabzug geschrieben)


Stacktrace:

Stack trace of thread 12790:
#0  0x7fb8965b304f raise (libc.so.6)
#1  0x7fb8965b447a abort (libc.so.6)
#2  0x7fb8965abea7 __assert_fail_base (libc.so.6)
#3  0x7fb8965abf52 __assert_fail (libc.so.6)
#4  0x006a7aa1
_ZNK8unit_map13iterator_baseINS_19standard_iter_typesEEptEv (wesnoth-debug)
#5  0x00e1be19
_ZL30synced_command_func_debug_killRK6configbbSt8functionIFvRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEbEE
(wesnoth-debug)
#6  0x007197e8
_ZN14synced_context3runERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERK6configbbSt8functionIFvS7_bEE
(wesnoth-debug)
#7  0x0071aa53
_ZN14synced_context13run_and_storeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERK6configbbSt8functionIFvS7_bEE
(wesnoth-debug)
#8  0x0071ab4b
_ZN14synced_context13run_and_throwERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERK6configbbSt8functionIFvS7_bEE
(wesnoth-debug)
#9  0x0101dad6
_ZN6events12menu_handler9kill_unitERNS_13mouse_handlerE (wesnoth-debug)
#10 0x01011790
_ZN21playsingle_controller14hotkey_handler9kill_unitEv (wesnoth-debug)
#11 0x0131ae63
_ZN6hotkey16command_executor15execute_commandERKNS_14hotkey_commandEib
(wesnoth-debug)
#12 0x010145c4
_ZN15play_controller14hotkey_handler15execute_commandERKN6hotkey14hotkey_commandEib
(wesnoth-debug)
#13 0x0131c4a8
_ZN6hotkey15execute_commandERKNS_14hotkey_commandEPNS_16command_executorEib
(wesnoth-debug)
#14 0x0131d242
_ZN6hotkeyL13event_executeERK9SDL_EventPNS_16command_executorE
(wesnoth-debug)
#15 0x0131d0fd
_ZN6hotkey9key_eventERK9SDL_EventPNS_16command_executorE (wesnoth-debug)
#16 0x009ab5de
_ZN15controller_base12handle_eventERK9SDL_Event (wesnoth-debug)
#17 0x012ef682 _ZN6events4pumpEv (wesnoth-debug)
#18 0x009ac1ec _ZN15controller_base10play_sliceEb
(wesnoth-debug)
#19 0x00dd5a4d
_ZN15play_controller16play_slice_catchEv (wesnoth-debug)
#20 0x00de52c8
_ZN21playsingle_controller15play_human_turnEv (wesnoth-debug)
#21 0x00de4111
_ZN21playsingle_controller14play_side_implEv (wesnoth-debug)
#22 0x00dd635f _ZN15play_controller9play_sideEv
(wesnoth-debug)
#23 0x00dd6627 _ZN15play_controller9play_turnEv
(wesnoth-debug)
#24 0x00de1c72
_ZN21playsingle_controller23play_scenario_main_loopEv (wesnoth-debug)
#25 0x00de2b9b
_ZN21playsingle_controller13play_scenarioERK6config (wesnoth-debug)
#26 0x00ab28a7
_ZN19campaign_controller19playsingle_scenarioER14end_level_data
(wesnoth-debug)
#27 0x00ab2ec2 _ZN19campaign_controller9play_gameEv
(wesnoth-debug)
#28 0x004dd1da
_ZN13game_launcher11launch_gameENS_16RELOAD_GAME_DATAE (wesnoth-debug)
#29 0x00466f33
_ZL11do_gameloopRKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE
(wesnoth-debug)
#30 0x00464b37 main (wesnoth-debug)
#31 0x7fb8965a0291 __libc_start_main (libc.so.6)
#32 0x004643ca _start (wesnoth-debug)

Stack trace of thread 12792:
   

[Wesnoth-bugs] [bug #25347] recruit window: unit scaling method

2016-11-30 Thread Severin Glöckner
URL:
  

 Summary: recruit window: unit scaling method
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Wed 30 Nov 2016 11:38:25 PM UTC
Category: Feature Request
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

I have the impression that the SCALE_SHARP method mentioned here is getting
used for scaling.
https://wiki.wesnoth.org/ImagePathFunctionWML#SCALE:_Image-scaling_function

I suppose that it looks better with the SCALE or XBRZ method.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25346] ~LIGHTEN() overlay image path function - how to use?

2016-11-30 Thread Severin Glöckner
URL:
  

 Summary: ~LIGHTEN() overlay image path function - how to use?
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Wed 30 Nov 2016 09:13:03 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

For an campaign image, I tried different image path functions.
(Tried it also with a profile= image.)

There is this one:
(https://wiki.wesnoth.org/ImagePathFunctionWML#LIGHTEN:_Overlay_function)
"Puts a time-of-day overlay on the image."

use results in

error display: unknown image function in path: LIGHTEN


Maybe it got removed?
Or there are additional restrictions on the use?




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25323] segfault after showing message about errors in an add-on

2016-11-20 Thread Severin Glöckner
URL:
  

 Summary: segfault after showing message about errors in an
add-on
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Mon 21 Nov 2016 04:07:04 AM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

I tried using sth like in an addon

#ifver <=1.13.4
small_profile="portraits/vampires/noble.png~SCALE(205,205)"
#endif

which should be #ifver WESNOTH_VERSION <=1.13.4


However, wesnoth did segfault after drooping the usual errormessage which gets
show for add-ons with broken WML.


Stack trace of thread 13764:
#0  0x0064 n/a (n/a)


(gdb) backtrace 
#0  0x0064 in  ()
#1  0x005b0be2 in gui2::widget::populate_dirty_list(gui2::window&,
std::vector >&)
(this=0x7f863c4521c0, caller=..., call_stack=std::vector of length 6, capacity
10 = {...}) at src/gui/widgets/widget.cpp:400
#2  0x0051e589 in gui2::grid::child_populate_dirty_list(gui2::window&,
std::vector > const&)
(this=0x7f863c2909d0, caller=..., call_stack=std::vector of length 5, capacity
8 = {...}) at src/gui/widgets/grid.cpp:603
#3  0x005b0be2 in gui2::widget::populate_dirty_list(gui2::window&,
std::vector >&)
(this=0x7f863c2909d0, caller=..., call_stack=std::vector of length 5, capacity
8 = {...}) at src/gui/widgets/widget.cpp:400
#4  0x0051e589 in gui2::grid::child_populate_dirty_list(gui2::window&,
std::vector > const&)
(this=0x7f863c3efc80, caller=..., call_stack=std::vector of length 4, capacity
6 = {...}) at src/gui/widgets/grid.cpp:603
#5  0x005b0be2 in gui2::widget::populate_dirty_list(gui2::window&,
std::vector >&)
(this=0x7f863c3efc80, caller=..., call_stack=std::vector of length 4, capacity
6 = {...}) at src/gui/widgets/widget.cpp:400
#6  0x00565a97 in
gui2::scrollbar_container::child_populate_dirty_list(gui2::window&,
std::vector > const&)
(this=0x7f863c02b890, caller=..., call_stack=std::vector of length 3, capacity
4 = {...})
at src/gui/widgets/scrollbar_container.cpp:870
#7  0x005b0be2 in gui2::widget::populate_dirty_list(gui2::window&,
std::vector >&)
(this=0x7f863c02b890, caller=..., call_stack=std::vector of length 3, capacity
4 = {...}) at src/gui/widgets/widget.cpp:400
#8  0x0051e589 in gui2::grid::child_populate_dirty_list(gui2::window&,
std::vector > const&)
(this=0x7f863c263900, caller=..., call_stack=std::vector of length 2, capacity
2 = {...}) at src/gui/widgets/grid.cpp:603
#9  0x005b0be2 in gui2::widget::populate_dirty_list(gui2::window&,
std::vector >&)
(this=0x7f863c263900, caller=..., call_stack=std::vector of length 2, capacity
2 = {...}) at src/gui/widgets/widget.cpp:400
#10 0x00a9f3e6 in
gui2::container_base::child_populate_dirty_list(gui2::window&,
std::vector > const&)
(this=0x7f863c2635d0, caller=..., call_stack=std::vector of length 1, capacity
1 = {...})
at src/gui/widgets/container_base.cpp:160
#11 0x005b0be2 in gui2::widget::populate_dirty_list(gui2::window&,
std::vector >&)
(this=0x7f863c2635d0, caller=..., call_stack=std::vector of length 1, capacity
1 = {...}) at src/gui/widgets/widget.cpp:400
#12 0x005b56b6 in gui2::window::draw() (this=0x7f863c2635d0) at
src/gui/widgets/window.cpp:864
#13 0x005c6da4 in std::__invoke_impl(std::__invoke_memfun_deref, void (gui2::window::*
const&)(), gui2::window*&) (__f=@0x722a690: (void
(gui2::window::*)(gui2::window * const)) 0x5b4db8 ,
__t=@0x722a6a0: 0x7f863c2635d0) at /usr/include/c++/6.2.1/functional:235
#14 0x005c61d6 in std::__invoke(void (gui2::window::* const&)(), gui2::window*&)
(__fn=@0x722a690: (void (gui2::window::*)(gui2::window * const)) 0x5b4db8
, __args#0=@0x722a6a0: 0x7f863c2635d0)
at /usr/include/c++/6.2.1/functional:260
#15 0x005c56b0 in std::_Mem_fn_base::operator()(gui2::window*&) const (this=0x722a690,
__args#0=@0x722a6a0: 0x7f863c2635d0) at 

[Wesnoth-bugs] [bug #25321] choose-game-to-load-screen with very long scenario name

2016-11-19 Thread Severin Glöckner
URL:
  

 Summary: choose-game-to-load-screen with very long scenario
name
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Sat 19 Nov 2016 11:01:45 PM UTC
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev, commit 049f067
Operating System: Archlinux

___

Details:

When having a very long scenario name, the dialog for choosing a game to load
gets a horizontal scroll bar

It would be better if the windows becomes wider.

Note that the game has only to be in the list, but not to be the selected one.
But the reason is that if we select the game, we would have to less place.




Other places where long scenario names could be a Problem?
- The scenario objectives window -> WORKS! (in difference to 1.12)
- Bug #25320



___

File Attachments:


---
Date: Sat 19 Nov 2016 11:01:45 PM UTC  Name: left.jpg  Size: 439kB   By: shiki


---
Date: Sat 19 Nov 2016 11:01:45 PM UTC  Name: right.jpg  Size: 470kB   By:
shiki



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25320] Statistics Dialog: To less place for scenario name

2016-11-19 Thread Severin Glöckner
Follow-up Comment #1, bug #25320 (project wesnoth):

Other picture, previously not included due to max size.

(file #29440)
___

Additional Item Attachment:

File name: super_long_text.jpgSize:401 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25320] Statistics Dialog: To less place for scenario name

2016-11-19 Thread Severin Glöckner
URL:
  

 Summary: Statistics Dialog: To less place for scenario name
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Sat 19 Nov 2016 10:56:21 PM UTC
Category: Feature Request
Severity: 1 - Wish
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev, commit 049f067
Operating System: Archlinux

___

Details:

It would look better it the Arrow is not overlapping with the text.

On the other hand, what would be a good way to deal with very long scenario
names?


Btw, the map changes on the first picture are great :)

(The border of the screen is black due to Bug #24984)



___

File Attachments:


---
Date: Sat 19 Nov 2016 10:56:21 PM UTC  Name: statistics_dialog.jpg  Size:
971kB   By: shiki



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25299] UTBS/Performance: unit movement over shroud is laggy

2016-11-15 Thread Severin Glöckner
Follow-up Comment #5, bug #25299 (project wesnoth):

I did build wesnoth again with your last commits.

Then it works. Only when the Hexagon is active it's bad.
And hexagon + alternative terrain drawing works quite good, but it's not the
same "good" like if all is disabled.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25303] workspace switching in fullscreen mode

2016-11-15 Thread Severin Glöckner
URL:
  

 Summary: workspace switching in fullscreen mode
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Tue 15 Nov 2016 12:20:22 PM UTC
Category: Bug
Severity: 4 - Important
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux Win10

___

Details:

One of the good things from the sdl2 movement is that it's now possible to
switch workspaces while you use fullscreen mode. For wesnoth that's in
particular good, since you have to wait between the rounds, and games often
take hours.
However, there are some bugs which should be fixed before 1.14:


When using fullscreen mode, by switching to another workspace and back,
wesnoth gets often, but not in every case, minimized.

E.g try this:
Use key combinations for workspace switching, possibly
ctrl+alt+(up/down)/(left/right) or ctrl+F1/F2/F3/F4
Start wesnoth on the second workspace.
Switching to the third and back is fine.
Switching to the first and back minimizes wesnoth.
(or the other way around)


Another possibility of switching workspaces are kind of overview modes.
In gnome 3, that's what you get with the [win] key.
In kde 5 exist many similar such modes (grid, cube, zylinder, ball, and more),
one of them is availaible with ctrl+F11, two others with ctrl+F9/F10. *
Windows 10 has as well sth. like this.

The problem is the same here. But what do these overview modes show when the
window got minimized (due to switching the workspace forth and back in
overview mode)?
 => see picture 1 & 2. When choosing the wesnoth windows again, everything is
fine.
When the wesnoth window is not minimized, then the wesnoth window looks normal
in the pverview, without broken map.


With much workspace switching something like that can happen too:
 => in gnome: see picture 3
 If I click away the message, all works fine.
 In kde I didn't happen to get such a message, maybe kde is more tollerant
there.
 In windows 10 I managed somehow to get a similar message (tough windows
doesn't allow me to click away the message and continue the game), but I can't
reproduce it. The key combination to switch workspaces in windows 10 is
ctrl+win+(right/left).


 
* "Allow Applications to block compositing" must be disabled in the system
settings -> hardware -> display -> compositor



___

File Attachments:


---
Date: Tue 15 Nov 2016 12:20:22 PM UTC  Name: picture_1(gnome).jpg  Size: 277kB
  By: shiki


---
Date: Tue 15 Nov 2016 12:20:22 PM UTC  Name: picture_2(kde).jpg  Size: 169kB  
By: shiki


---
Date: Tue 15 Nov 2016 12:20:22 PM UTC  Name: picture_3.jpg  Size: 432kB   By:
shiki



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25299] UTBS/Performance: unit movement over shroud is laggy

2016-11-14 Thread Severin Glöckner
Follow-up Comment #3, bug #25299 (project wesnoth):

That's it, on 100x100 it's really bad.

Without minimap terrain drawing it's as bad as with.

I also noticed that campaigns take longer to load - there's a ~2 sec delay
before the characters talking starts and the scenario prologue takes as well a
bit longer.
(in difference to before I compare with 1.12, not 1.13.4)

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #24984] KDE5: wesnoth startup problem with fullscreen mode

2016-11-14 Thread Severin Glöckner
Follow-up Comment #4, bug #24984 (project wesnoth):

Tested it again with current master and gnome 3.22.1 / kde 5.8.3
 - gnome starts fine now with DRI 3. Maybe not totally fancy (for a moment it
looks like in the attachement), but no problems
 - kde startup remains the same


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25299] UTBS/Performance: unit movement over shroud is laggy

2016-11-14 Thread Severin Glöckner
URL:
  

 Summary: UTBS/Performance: unit movement over shroud is laggy
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Mon 14 Nov 2016 04:15:30 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

1)Build the debug version of wesnoth 1.13.6(+dev)
2) Start the first scenario of UTBS (doesn't matter if the reamke or the old)
3)send a unit to the north, or somewhere else where much shroud is.

When a unit discovers shrouded area in it's movement, there's graphically a
short delay between each hex.
Compared to 1.13.4, this effect does exist there too, but the delays are
shorter.
If you build the release version of wesnoth 1.13.4, together with
march=native, the delays are even more short.

When I used the random map generator in 1.13.6+dev and enabled shroud, there
weren't delays.
Not sure if Graphics are the problem, or rather some UTBS events.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #24986] KDE5: compositing with OpenGL breaks after closing wesnoth.

2016-11-14 Thread Severin Glöckner
Follow-up Comment #5, bug #24986 (project wesnoth):

It's not happening fo me either anymore (kde 5.8).
So I will use the OpenGL setting again :)

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25288] Crash if wesnoth resolution is higher than desktop resolution.

2016-11-13 Thread Severin Glöckner
Follow-up Comment #2, bug #25288 (project wesnoth):

I suppose so.

I remember that there comes usually an error message saying something about
Xorg and exits then.

This could be changed to =)

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25291] translations - alignment is sometimes shown translated, sometimes not

2016-11-12 Thread Severin Glöckner
URL:
  

 Summary: translations - alignment is sometimes shown
translated, sometimes not
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Sun 13 Nov 2016 05:02:32 AM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Translations
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

For some units the alignment is shown translated, for others not. I can't see
a pattern there. It's not the WML, it happens to mainline units too.
Affects all places where the alignment get's shown.
I think this bug was introduced with 1.13.4.



___

File Attachments:


---
Date: Sun 13 Nov 2016 05:02:32 AM UTC  Name: Alignments.jpg  Size: 226kB   By:
shiki



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25288] Crash if wesnoth resolution is higher than desktop resolution.

2016-11-12 Thread Severin Glöckner
URL:
  

 Summary: Crash if wesnoth resolution is higher than desktop
resolution.
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Sat 12 Nov 2016 06:52:20 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Graphics
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.6+dev
Operating System: Archlinux

___

Details:

When the desktop resolution is lower then the resolution used the last time in
wesnoth, it segfaults on startup.

https://bpaste.net/show/c77216cb59be




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25013] weapon naming: with or without space?

2016-08-23 Thread Severin Glöckner
URL:
  

 Summary: weapon naming: with or without space?
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Tue 23 Aug 2016 11:45:18 PM UTC
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group: WML
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.5+dev
Operating System: Archlinux

___

Details:

The Khalifate units have weapons called "long sword".
The Loyalists call them "longsword".

Whatever the better version is, it should be the same for both.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25004] [HELP] Portrait gets not shown properly anymore

2016-08-22 Thread Severin Glöckner
Follow-up Comment #4, bug #25004 (project wesnoth):

This is from Rise of the Elementalists, they appear in the 2nd scenario. If
you stark the game in debug mode you can choose the scenario directly.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #25004] Portrait gets not shown properly anymore

2016-08-21 Thread Severin Glöckner
URL:
  

 Summary: Portrait gets not shown properly anymore
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Sun 21 Aug 2016 07:17:00 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.5
Operating System: Archlinux

___

Details:

Something changed since 1.13.4, and this image get's shown buggy. (On image
itself or the wml nothing changed.)



___

File Attachments:


---
Date: Sun 21 Aug 2016 07:17:00 PM UTC  Name: 1_13_4-working.jpg  Size: 244kB  
By: shiki


---
Date: Sun 21 Aug 2016 07:17:00 PM UTC  Name: 1_13_5+dev-broken.jpg  Size:
245kB   By: shiki


---
Date: Sun 21 Aug 2016 07:17:00 PM UTC  Name: the_image.png  Size: 82kB   By:
shiki



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #24986] KDE5: compositing with OpenGL breaks after closing wesnoth.

2016-08-19 Thread Severin Glöckner
Follow-up Comment #3, bug #24986 (project wesnoth):

About screen tearing in KDE, I got rid of it in almost cases with setting
Tearing prevention ("vsync")[see linked picture] to never (yes, ironically
this helped a lot. Just don't leave it as automatic)
and adding /etc/X11/xorg.conf.d/20-intel.conf with

Section "Device"
   Identifier "Intel Graphics"
   Driver "intel"
   Option "TearFree" "true" 
EndSection


Maybe somebody can link to this upstream?


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #24984] KDE5: wesnoth startup problem with fullscreen mode

2016-08-19 Thread Severin Glöckner
Follow-up Comment #3, bug #24984 (project wesnoth):

About the gnome part, 1-2 weeks ago, xf86-video-intel in Archlinux switched
default to DRI 3, if I set DRI to 2 this problem doesn't occur.

KDE part remains the same.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #24988] scrollbar in attack dialog

2016-08-19 Thread Severin Glöckner
Follow-up Comment #7, bug #24988 (project wesnoth):

It's fixed, thanks.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #24988] scrollbar in attack dialog

2016-08-16 Thread Severin Glöckner
URL:
  

 Summary: scrollbar in attack dialog
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Tue 16 Aug 2016 07:45:17 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.5+dev
Operating System: Archlinux

___

Details:

In some cases is a scroll bar in the attack dialog. I don't know because of
what.

Some cases with english language are:
Troll Rocklober vs Elvish Archer
Troll Rocklober vs Red Mage
Orcish Assassin vs Red Mage

Orcish Assassin vs Elvish archer is fine
Orcish Assassin vs Mage is fine too

The case on the screenshot is fine with english language.
And it doesn't matter if you swap defender and attacker in the dialog.



___

File Attachments:


---
Date: Tue 16 Aug 2016 07:45:17 PM UTC  Name: attack_dialog.jpg  Size: 732kB  
By: shiki



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #24986] KDE5: compositing with OpenGL breaks after closing wesnoth.

2016-08-16 Thread Severin Glöckner
URL:
  

 Summary: KDE5: compositing with OpenGL breaks after closing
wesnoth.
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Tue 16 Aug 2016 07:08:26 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: since 1.13.4
Operating System: Archlinux

___

Details:

In the KDE settings are three different options for the rendering backend.
https://i.imgur.com/BxlLXGV.png
XRender works fine.
The two OpenGL options work fine while (and before) playing wesnoth, but after
closing wesnoth KDE gets terrible. Pictures tell more than words, see the
screenshots.



___

File Attachments:


---
Date: Tue 16 Aug 2016 07:08:26 PM UTC  Name: Screenshot_20160808_220910.png 
Size: 449kB   By: shiki


---
Date: Tue 16 Aug 2016 07:08:26 PM UTC  Name: Screenshot_20160808_221053.png 
Size: 456kB   By: shiki



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #24984] KDE5: wesnoth startup problem with fullscreen mode

2016-08-16 Thread Severin Glöckner
Follow-up Comment #2, bug #24984 (project wesnoth):

I thought in gnome are no problems, but ... - they just appear after launching
wesnoth the 2nd time.

Switching workspaces brings me to the normal startscreen.
Same if I press the screenshot button, or if i press the key for adjusting the
lightning or audio.
E.g. I use the win/super key, and it seems that the wesnoth screen just
refreshes every time I press the win key twice. So, I click the add-ons
button, but it looks like nothing happens, but after pressing the win key
twice i see that something happened.

I attached a photo of the screen I get initially. When starting wesnoth the
FIRST time, this get's shown shortly too, but then the game normal screen
shows up.

(file #28363)
___

Additional Item Attachment:

File name: gnome-2nd-startup.jpg  Size:368 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #24984] KDE5: wesnoth startup problem with fullscreen mode

2016-08-16 Thread Severin Glöckner
URL:
  

 Summary: KDE5: wesnoth startup problem with fullscreen mode
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Tue 16 Aug 2016 12:33:02 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.5+dev
Operating System: Archlinux

___

Details:

When using KDE5, this is what it looks like when I start the game.
Using Alt+Tab twice, or Alt+Tab and clicking on the icon in taskbar, then
fullscreen works. (otherwise it stays the whole game like that)


Also, if I instead switch the workspace after startup, the game is shown as
minimized in the taskbar.
If I instead first resolve the fullscreen problem like shown above, then it
isn't. (like it should be)


For the case you wonder, it has no effect if you click on the part of the
desktop which is shown on the screenshot.



___

File Attachments:


---
Date: Tue 16 Aug 2016 12:33:02 PM UTC  Name: after_startup.jpg  Size: 891kB  
By: shiki



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #24983] Screen messages like "xx created a unit using debug mode" overlap

2016-08-16 Thread Severin Glöckner
URL:
  

 Summary: Screen messages like "xx created a unit using debug
mode" overlap
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Tue 16 Aug 2016 10:58:39 AM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.5+dev
Operating System: Archlinux

___

Details:

When creating a unit with debug mode, and killing one directly afterwards
using debug mode, both messages overlap.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #24697] wesnoth crashes after a specific prerecruit event

2016-07-18 Thread Severin Glöckner
Follow-up Comment #1, bug #24697 (project wesnoth):

Seems like 
https://github.com/wesnoth/wesnoth/commit/2d7d6a0dde2a7426f99d3502f959cf82b2fda93f
fixed it.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #24853] Ghazi/Shuja/Khalid missing {SOUND:SLOW}

2016-07-15 Thread Severin Glöckner
Follow-up Comment #2, bug #24853 (project wesnoth):

True, there's no problem. Sorry for that.
We could remove the macro definitions then as well.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #24853] Ghazi/Shuja/Khalid missing {SOUND:SLOW}

2016-07-13 Thread Severin Glöckner
URL:
  

 Summary: Ghazi/Shuja/Khalid missing {SOUND:SLOW}
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Wed 13 Jul 2016 11:04:19 AM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: WML
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.4+dev
Operating System: Archlinux

___

Details:

The Ghazi/Shuja/Khalid line misses {SOUND:SLOW}
In the 1.12 files is a note that there was a bug, in 1.13 it seems to have
gotten lost.

2 more things:
would the recently added icons/silver_bucker.png fit better as shield attack
icon?
for getting the Khalid you need, if enabled, 150 xp. All lvl 3 units in
wesnoth so far need at least 180 xp for lvl4.





___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs


[Wesnoth-bugs] [bug #24743] Pythontools: wesnoth-optipng, unable to compare compressed and original images

2016-06-09 Thread Severin Glöckner
URL:
  

 Summary: Pythontools: wesnoth-optipng, unable to compare
compressed and original images
 Project: Battle for Wesnoth
Submitted by: shiki
Submitted on: Thu 09 Jun 2016 03:29:57 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: WML Tools
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.4, 1.12.6
Operating System: Archlinux

___

Details:

All Python2 Tools need
#! /usr/bin/env python2
in their first line to work on newer systems too.


And the script /utils/compare-images.py (gets used by wesnoth-optipng) uses
one function, which got removed.

Luckily .tobytes() mimics the behavior of .tostring().

The bug in compare-images.py won't abort wesnoth-optipng.
This makes a difference for images which don't use mode rgb, but mode
indicated.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs