[Wesnoth-bugs] [bug #25074] Shavian English date formatting is incorrect and causes crashes

2016-09-28 Thread Wedge009
Update of bug #25074 (project wesnoth):

  Status:None => Fixed  
 Assigned to:None => espreon


___

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 #25132] Building failure with Clang C++ compiler

2016-09-28 Thread Daniel
Update of bug #25132 (project wesnoth):

  Status:None => Upstream Problem   

___

Follow-up Comment #5:

We reported this on boost https://svn.boost.org/trac/boost/ticket/12397 and it
will be fixed on next boost version (1.62 i think that is).

Until then the only known way to solve this issue is to eigher use another
boost version (boost 1.59 or eariler) or edit the boost files eigher by
removing 'BOOST_CONSTEXPR' or by applying the fix linked in the boost
bugreport.

Marking this as upstream problem which doesn't means that you shouldn't commit
a workaround if you find onw.

___

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 #25132] Building failure with Clang C++ compiler

2016-09-28 Thread Charles Dang
Follow-up Comment #4, bug #25132 (project wesnoth):

It still happens with gcc sometimes. One can simply remove the
'BOOST_CONSTEXPR' statement from the line above the static_assert and it works
fine.

___

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 #25132] Building failure with Clang C++ compiler

2016-09-28 Thread Matthias Krüger
Follow-up Comment #3, bug #25132 (project wesnoth):

In your ticket you wrote you have "boost 1.16.1", are you sure about that?
Boost 1.16 is from 2000, wesnoth requires boost 1.48.0 as can be read in the
INSTALL file.

I had similar problem with boost 1.60.0 though.

As you can see from the output you posted, the compilation failure happens in
boost and not wesnoth itself so this is actually a boost bug which happens to
affect wesnoth.

There were some changes made here:
https://github.com/boostorg/bind/commit/3c56630b5400c43d1a4393d685a407e68a69ce9e

Laster boost version might have this fixed.

The easiest solution might be to just compile with gcc or upgrade/downgrade
boost.

___

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 #25111] tutorial: getting stuck sometimes, have to undo turn or reload

2016-09-28 Thread Matthias Krüger
Follow-up Comment #2, bug #25111 (project wesnoth):

Yes, but usually you can end you turn whenever you want but the tutorial keeps
you from doing so.

___

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 #25111] tutorial: getting stuck sometimes, have to undo turn or reload

2016-09-28 Thread Matthias Krüger
Follow-up Comment #4, bug #25111 (project wesnoth):

It's completely unrelated to regular (non-tutorial) gameplay.

It only affects the tutorial.
The problem is not that units can no longer move after attacking/capturing
villages.

The problem is that the tutorial, and only the tutorial, requires the player
to do exactly as planned. If a player plays around a bit or misclicks and
accidentally moves the unit somewhere where the tutorial did not foresee it,
which can totally happen since new player are new to the game, they will get
into a situation where you no longer progress unless by doing (for new people)
advanced things like undoing actions (in the best case) or completely
reloading a turn (in the worst case).

People are NOT supposed to get frustrated in the tutorial already, they might
just quit the game forever.

Did you actually try to reproduce this ingame?

___

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 #25111] tutorial: getting stuck sometimes, have to undo turn or reload

2016-09-28 Thread Zheng Lv
Follow-up Comment #1, bug #25111 (project wesnoth):

It's design of the game. When your unit occupy a village (which did not belong
to you), it will lose all its moving points. Attacking also costs all moving
points of a unit.

It's really not a bug. It's just how wesnoth is designed to be.

___

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 #25111] tutorial: getting stuck sometimes, have to undo turn or reload

2016-09-28 Thread Zheng Lv
Follow-up Comment #3, bug #25111 (project wesnoth):

I see. It think it is not a bug, as it does not affect gameplay. You should
have post it as a Feature Request. Maybe this feature should be further
discussed.

___

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 #25132] Building failure with Clang C++ compiler

2016-09-28 Thread Zheng Lv
URL:
  

 Summary: Building failure with Clang C++ compiler
 Project: Battle for Wesnoth
Submitted by: lvzheng
Submitted on: Wed 28 Sep 2016 02:14:11 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
Operating System: Linux

___

Details:

How to reproduce this bug:

git checkout -b some_branch 1.13.5
mkdir ../build && cd ../build
ccmake ../wesnoth
# Set C++ compiler to clang++, C compiler to clang, enable campaign server.
This is what I did.
make (possibly -jXXX)

Compile error at 'Building CXX object
src/CMakeFiles/wesnoth.dir/gui/widgets/button.cpp.o'


[ 81%] Building CXX object
src/CMakeFiles/wesnoth.dir/gui/widgets/button.cpp.o
In file included from
/home/lvzheng/gits/wesnoth/src/gui/widgets/button.cpp:17:
/home/lvzheng/gits/wesnoth/src/gui/widgets/button.hpp:49:7: warning:
'connect_click_handler' overrides a member function but is not marked
'override' [-Winconsistent-missing-override]
 void connect_click_handler(const event::tsignal_function& signal)
  ^
/home/lvzheng/gits/wesnoth/src/gui/widgets/clickable.hpp:53:15: note:
overridden virtual function is here
 virtual void connect_click_handler(const event::tsignal_function& signal)
  ^
In file included from
/home/lvzheng/gits/wesnoth/src/gui/widgets/button.cpp:17:
/home/lvzheng/gits/wesnoth/src/gui/widgets/button.hpp:55:7: warning:
'disconnect_click_handler' overrides a member function but is not marked
'override' [-Winconsistent-missing-override]
 void disconnect_click_handler(const event::tsignal_function& signal)
  ^
/home/lvzheng/gits/wesnoth/src/gui/widgets/clickable.hpp:64:15: note:
overridden virtual function is here
 virtual void disconnect_click_handler(const event::tsignal_function& signal)
  ^
In file included from
/home/lvzheng/gits/wesnoth/src/gui/widgets/button.cpp:23:
In file included from
/home/lvzheng/gits/wesnoth/src/gui/core/window_builder/helper.hpp:18:
In file included from
/home/lvzheng/gits/wesnoth/src/gui/widgets/scrollbar_container.hpp:20:
/home/lvzheng/gits/wesnoth/src/gui/widgets/scrollbar.hpp:352:7: warning:
'load_config_extra' overrides a member function but is not marked 'override'
[-Winconsistent-missing-override]
 void load_config_extra();
  ^
/home/lvzheng/gits/wesnoth/src/gui/widgets/control.hpp:405:15: note:
overridden virtual function is here
 virtual void load_config_extra()
  ^
In file included from
/home/lvzheng/gits/wesnoth/src/gui/widgets/button.cpp:17:
In file included from
/home/lvzheng/gits/wesnoth/src/gui/widgets/button.hpp:19:
In file included from
/home/lvzheng/gits/wesnoth/src/gui/core/window_builder.hpp:19:
In file included from /home/lvzheng/gits/wesnoth/src/gui/widgets/grid.hpp:18:
In file included from
/home/lvzheng/gits/wesnoth/src/gui/widgets/widget.hpp:18:
In file included from
/home/lvzheng/gits/wesnoth/src/gui/core/event/dispatcher.hpp:25:
In file included from /home/lvzheng/gits/wesnoth/src/utils/functional.hpp:23:
In file included from /usr/include/boost/bind.hpp:22:
In file included from /usr/include/boost/bind/bind.hpp:29:
/usr/include/boost/bind/arg.hpp:37:9: error: static_assert failed "I ==
is_placeholder::value"
static_assert(I == is_placeholder::value, "I ==
is_placeholder::value");
^ ~
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/type_traits:1476:46:
note: in instantiation of function template specialization
'boost::arg<1>::arg > >' requested here
typename = decltype(__test_aux<_To1>(std::declval<_From1>()))>
 ^
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/type_traits:1478:2:
note: in instantiation of default argument for '__test > &, boost::arg<1> >' required here
 __test(int);
 ^~~
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/type_traits:1485:24:
note: while substituting deduced template arguments into function template
'__test' [with _From1 = const std::tuple > &, _To1 =
boost::arg<1>, $2 = (no value)]
  typedef decltype(__test<_From, _To>(0)) type;
   ^
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/type_traits:1492:14:
note: in instantiation of template class 'std::__is_convertible_helper > &, boost::arg<1>, false>' requested here
: public __is_convertible_helper<_From, _To>::type
 ^
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/type_traits:133:14:
note: in instantiation of template class 'std::is_convertible > &, boost::arg<1> >' 

[Wesnoth-bugs] [bug #25132] Building failure with Clang C++ compiler

2016-09-28 Thread Zheng Lv
Follow-up Comment #1, bug #25132 (project wesnoth):

Update:

Forcing clang to use libc++ as stdlib also fails, but on a different file,
however.


[ 80%] Building CXX object
src/CMakeFiles/wesnoth.dir/gui/core/event/distributor.cpp.o
In file included from
/home/lvzheng/gits/wesnoth/src/gui/core/event/distributor.cpp:17:
In file included from
/home/lvzheng/gits/wesnoth/src/gui/core/event/distributor.hpp:41:
In file included from
/home/lvzheng/gits/wesnoth/src/gui/core/event/dispatcher.hpp:25:
In file included from /home/lvzheng/gits/wesnoth/src/utils/functional.hpp:23:
In file included from /usr/include/boost/bind.hpp:22:
In file included from /usr/include/boost/bind/bind.hpp:29:
/usr/include/boost/bind/arg.hpp:37:9: error: static_assert failed "I ==
is_placeholder::value"
static_assert(I == is_placeholder::value, "I ==
is_placeholder::value");
^ ~
/usr/bin/../include/c++/v1/type_traits:1290:66: note: in instantiation of
function template specialization 'boost::arg<2>::arg >'
requested here
: public integral_constant >'
requested here
   is_convertible<_Tp0, _Up0>::value &&
   ^
/usr/bin/../include/c++/v1/__tuple:257:32: note: in instantiation of template
class 'std::__1::__tuple_convertible_imp, std::__1::__tuple_types > >' requested here
   __tuple_convertible_imp<__tuple_types<_Tp...>,
__tuple_types<_Up...> >::value> {};
   ^
/usr/bin/../include/c++/v1/__tuple:268:12: note: in instantiation of template
class 'std::__1::__tuple_convertible_imp &>,
std::__1::__tuple_types > >'
requested here
  : public __tuple_convertible_imp<
   ^
/usr/bin/../include/c++/v1/__tuple:281:14: note: in instantiation of template
class 'std::__1::__tuple_convertible_apply &>,
std::__1::__tuple_types > >'
requested here
: public __tuple_convertible_apply::value ==
 ^
/usr/bin/../include/c++/v1/tuple:635:26: note: in instantiation of template
class 'std::__1::__tuple_convertible &>, std::__1::__tuple_types >, true, true>' requested here
 __tuple_convertible
 ^
/usr/bin/../include/c++/v1/tuple:652:9: note: in instantiation of default
argument for 'tuple, const boost::arg<3> &, const boost::arg<5>
&>' required here
tuple(allocator_arg_t, const _Alloc& __a, _Up&&... __u)
^
/usr/bin/../include/c++/v1/functional:2227:11: note: while substituting
deduced template arguments into function template 'tuple' [with _Alloc =
boost::arg<2>, _Up =  &, const boost::arg<5> &>, $2 = (no
value)]
  __bound_args_(std::__1::forward<_BA>(__bound_args)...) {}
  ^
/usr/bin/../include/c++/v1/functional:2337:12: note: in instantiation of
function template specialization 'std::__1::__bind &, const
boost::arg<3> &, const boost::arg<5> &>::__bind &, const
boost::arg<3> &, const boost::arg<5> &, void>' requested here
return type(std::__1::forward<_Fp>(__f),
std::__1::forward<_BoundArgs>(__bound_args)...);
   ^
/home/lvzheng/gits/wesnoth/src/gui/core/event/distributor.cpp:124:9: note: in
instantiation of function template specialization 'std::__1::bind &, const
boost::arg<3> &, const boost::arg<5> &>' requested here
   std::bind(_motion::signal_handler_sdl_mouse_motion,
^
In file included from
/home/lvzheng/gits/wesnoth/src/gui/core/event/distributor.cpp:17:
In file included from
/home/lvzheng/gits/wesnoth/src/gui/core/event/distributor.hpp:41:
In file included from
/home/lvzheng/gits/wesnoth/src/gui/core/event/dispatcher.hpp:25:
In file included from /home/lvzheng/gits/wesnoth/src/utils/functional.hpp:23:
In file included from /usr/include/boost/bind.hpp:22:
In file included from /usr/include/boost/bind/bind.hpp:29:
/usr/include/boost/bind/arg.hpp:37:9: error: static_assert failed "I ==
is_placeholder::value"
static_assert(I == is_placeholder::value, "I ==
is_placeholder::value");
^ ~
/usr/bin/../include/c++/v1/type_traits:1290:66: note: in instantiation of
function template specialization 'boost::arg<5>::arg >'
requested here
: public integral_constant >'
requested here
   

[Wesnoth-bugs] [bug #25132] Building failure with Clang C++ compiler

2016-09-28 Thread Zheng Lv
Follow-up Comment #2, bug #25132 (project wesnoth):

Update:

Others have the same problem.

https://forums.wesnoth.org/viewtopic.php?f=5=600277

They solved this problem by hacking. Do we have a better solution?

___

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 #25131] [move_unit] check_passability=no doesn't work

2016-09-28 Thread Lari Nieminen
Update of bug #25131 (project wesnoth):

 Release: 1.2 and 1.3 => 1.3.5+dev  


___

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 #25131] [move_unit] check_passability=no doesn't work

2016-09-28 Thread Lari Nieminen
URL:
  

 Summary: [move_unit] check_passability=no doesn't work
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Wed 28 Sep 2016 12:27:47 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.2 and 1.3
Operating System: win7

___

Details:

Use of [move_unit] check_passability=no seems to have no effect; if you use
that while attempting to move a unit to an impassable hex, the unit will
simply move to an adjacent passable hex instead (the same way it does when
check_passability=yes).




___

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 #25130] Add-On Options Dialogue Results in Deadlocked UI

2016-09-28 Thread Wedge009
URL:
  

 Summary: Add-On Options Dialogue Results in Deadlocked UI
 Project: Battle for Wesnoth
Submitted by: wedge009
Submitted on: Wed 28 Sep 2016 07:55:00 PM AEST
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: All

___

Details:

Follow-on from bug #25073. Clicking the Options button in the Add-Ons dialogue
results in a locked game - it responds to mouse clicks but no other course of
action is available other than to close the game.




___

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 #25073] Development build fails to parse add-ons server data

2016-09-28 Thread Wedge009
Follow-up Comment #3, bug #25073 (project wesnoth):

Huh, I forgot about the Options button.

___

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 #25073] Development build fails to parse add-ons server data

2016-09-28 Thread Ignacio R. Morelle
Update of bug #25073 (project wesnoth):

  Status:None => Fixed  
 Assigned to:None => shadowmaster   
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

The empty add-ons list (actually not completely empty if you have local
add-ons with pbl files) was introduced by commit
fe08701b7ca3639b17dca20023d2bb34433042c6
,
fixed by c26b13372b7370e11c899a24d4149130f41451d8
.

You should file a separate bug for the Options dialog bug, it seems completely
unrelated and it's probably the consequence of some change in the GUI1 and/or
GUI2 event handling code.

___

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 #25093] editor: heap buffer overflow editing side of scenario

2016-09-28 Thread Charles Dang
Update of bug #25093 (project wesnoth):

  Status:  Ready For Test => Fixed  
 Open/Closed:Open => Closed 


___

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 #25110] invisible standing frame

2016-09-28 Thread Charles Dang
Update of bug #25110 (project wesnoth):

  Status:None => Ready For Test 
 Assigned to:None => vultraz

___

Follow-up Comment #1:

This should be fixed as of bee748329b35cc.

___

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