[Wesnoth-bugs] [bug #25173] [text_input] doesn't display when no label is specified

[Gregory A Lundberg]

Update of bug #25173 (project wesnoth):

  Status:   Confirmed => Fixed  
 Assigned to:None => tad_carlucci   
 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 #25227] assertion failure when normal/planned moves conflict

[Wedge009]

Follow-up Comment #1, bug #25227 (project wesnoth):

From what you describe, it sounds like this is a problem. However, I can't
replicate the issue.

I have a unit starting at hex A. I make a move which requires several turns:
it moves to hex B for this turn, and will move to hex C in the next turn.

Before ending my turn, I plan some moves where it will go to hex D instead of
hex C in the next turn. Upon ending my turn and going to the next turn, the
unit goes to hex C and the planned move to hex D is invalid, so the planned
moves are discarded. I confirm that turn_of_position is zero when this happens
too.

It doesn't seem to make a difference when I make the planned moves diverge
later, eg the planned move as well as the regular move goes to hex C, but then
the regular and planned moves diverge after that - the planned moves just
become invalid (and are thus removed) when that happens.

___

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 #25222] crash in planning mode, moving planned recruit

[Wedge009]

Follow-up Comment #5, bug #25222 (project wesnoth):


wesnoth.exe!wb::side_actions_container::queue(unsigned int turn_num,
std::shared_ptr action) Line 163C++
wesnoth.exe!wb::side_actions::synced_enqueue(unsigned int turn_num,
std::shared_ptr act) Line 659   C++
wesnoth.exe!wb::side_actions::queue_action(unsigned int turn_num,
std::shared_ptr action) Line 413C++
wesnoth.exe!wb::side_actions::queue_move(unsigned int turn, unit & mover,
const pathfind::marked_route & route, std::shared_ptr arrow,
fake_unit_ptr fake_unit) Line 677   C++
wesnoth.exe!wb::manager::save_temp_move() Line 787  C++
wesnoth.exe!events::mouse_handler::move_action(bool browse) Line 699C++


In manager::save_temp_move() there is a loop to add temporary (presumably
planning-mode) moves to a queue. This is the loop I was referring to - with
each loop increment num_turns() in side_actions_container::queue() also
increments.

___

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 #25186] [message] lag

[Daniel]

Follow-up Comment #15, bug #25186 (project wesnoth):

Well, at least we have a workaround then: we could add an
wesnoth.wml_actions.redraw {} at the end of the lua [message]
implmementation.


I think one possible reason why this lag appears is that here
https://github.com/wesnoth/wesnoth/blob/1.13.5/src/gui/widgets/window.cpp#L616
it might happen that if the new window is shown before before the draw timer
of the old window has stopped, the code will creatre another draw timer so
that the there will not twice as many draw events in the queue repating  this
process over and over coudl thne result in 3 or more as many draw events
beeing fired.


I also think the reason why this doesn't happen with speaker=unit is that we
here
https://github.com/wesnoth/wesnoth/blob/1.13.5/data/lua/wml/message.lua#L357
issue a [redraw] in case that a valid unit was chosen as speaker 

___

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 #25186] [message] lag

[Pentarctagon]

Follow-up Comment #14, bug #25186 (project wesnoth):

It does.  The cpu usage still goes up to 7-9%, but it drops back to 4% once I
stop clicking, and the UI never lags or freezes.

___

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 #25173] [text_input] doesn't display when no label is specified

[Gregory A Lundberg]

Follow-up Comment #4, bug #25173 (project wesnoth):

See PR 841 for fix

___

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 #25186] [message] lag

[Daniel]

Follow-up Comment #12, bug #25186 (project wesnoth):

Desow the lag o away if you add a [redraw] after the [message]?

___

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 #25186] [message] lag

[Daniel]

Follow-up Comment #13, bug #25186 (project wesnoth):

go*

___

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 #25186] [message] lag

[Daniel]

Follow-up Comment #11, bug #25186 (project wesnoth):

In the discussion here:
https://www.wesnoth.org/irclogs/2016/10/%23wesnoth-dev.2016-10-24.log starting
with 


20161024 16:53:33< tad_carlucci> gfgtdf, HttT S01 I can cause issues with any
[message] speaker= does not seem to be related. Speed of cliking is. Resizing
main window is.


tad said its unrelated to speaker. Not sure what to believe now.

___

Reply to this item at:

  <http://gna.org/bugs/?25186>

___
  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 #25227] assertion failure when normal/planned moves conflict

[Matthias Krüger]

URL:
  

 Summary: assertion failure when normal/planned moves conflict
 Project: Battle for Wesnoth
Submitted by: matthiaskrgr
Submitted on: Mon 24 Oct 2016 14:00:32 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: v1.13.5+dev (f4870a8-Clean)
Operating System: linux

___

Details:

Have unit
Also make a regular movement lasting severl turns to some hex on the map.
Enter planning mode, make a planned movement to some other hex in planning
mode.

End turn.
=> on the next turn of that unit, the game will crash:

wesnoth:
/home/matthias/vcs/github/wesnoth/src/whiteboard/side_actions.cpp:228:
wb::side_actions_container::iterator
wb::side_actions_container::erase(wb::side_actions_container::iterator):
Assertion `turn_of_position == 0' failed.


Might be related: https://gna.org/bugs/index.php?25222




___

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 #19320] Chat log should show latest messages, not oldest

[Charles Dang]

Update of bug #19320 (project wesnoth):

  Status:  Ready For Test => In Progress

___

Follow-up Comment #3:

Ok, that did not fully fix it. I improved the situation here:
https://github.com/wesnoth/wesnoth/commit/d8027de68fe645ac394d29ad6f579c5f31675da2
but that doesn't fix the scrollbar position on first run... will have to
investigate further.

The invalidate_layout calls were in order to recalculate size if the initial
page was less than max height. However, they also reset the scrollbar position
to the top. Now that I've made the dialog fixed-size as well, these calls are
redundant. Dropping them fixes the scroll-to-bottom behavior for paging and
filtering, just not the initial run.

___

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 #25080] UB in map resize window

[Wedge009]

Follow-up Comment #7, bug #25080 (project wesnoth):

I know that, I was speaking generally.

Also, my point was that it was a different situation to the report I mentioned
previously. Not really sure what you're trying to say with all your typing
errors anyway.

Regardless, in this case, it does look like the expand direction member needs
to be a reference.

___

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 #25080] UB in map resize window

[Daniel]

Follow-up Comment #6, bug #25080 (project wesnoth):

This is actuall nothing related to c++11/14/17 features.

> But in this case expand_direction_ is a private member of the
teditor_resize_map class.

This is provate doesn tmant that the actual pbject is points to is also a
member of the teditor_resize_map  class.

>  Is it really necessary or helpful to have it as a reference?

Wll you can locally try to change to be a value, butmy guess is that the map
resizing in the esitor just won't work then.

___

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