[Wesnoth-bugs] [bug #25222] crash in planning mode, moving planned recruit

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

2016-10-23 Thread Daniel 
Follow-up Comment #2, bug #25222 (project wesnoth):

> when I was testing, num_turns() returned 1 and it was the first turn of the
game

You know what the 'turn_num' variable was?


___

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

2016-10-23 Thread Wedge009 
Update of bug #25222 (project wesnoth):

  Status:None => Confirmed  
 Release: git => 1.13.5+dev 
Operating System:   linux => All

___

Follow-up Comment #1:

I hate planning mode and I hate planned recruits in particular. ): Maybe I
should re-introduce my PR to disable planned recruits altogether.


//for a little extra safety, since we should never resize by much at a time
assert(turn_num <= num_turns() || future_only);


I'm not sure if anyone still active really knows what the planning code is
doing. But the general way to replicate this issue is to plan a recruit and
then plan several turns of movement (when I was testing, num_turns() returned
1 and it was the first turn of the game).

I disabled planned movements on planned recruits a while back but it only
cancels the planned movement when you attempt to add it to the queue. So I
suppose there's still some background processing involved which is where this
assertion gets hit. Incidentally, ignoring the assertion failure seems okay...
until you go to close the game in which case there's another crash/exception,
presumably due to the assertions failing the first time around.

___

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

2016-10-23 Thread Matthias Krüger 
URL:
  

 Summary: crash in planning mode, moving planned recruit
 Project: Battle for Wesnoth
Submitted by: matthiaskrgr
Submitted on: Sun 23 Oct 2016 10:40:46 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: git
Operating System: linux

___

Details:

start game on sablestone delta with FoW but no shroud as undead
move leader to keep
start planning mode
in planning mode:
recruit skeleton
select planned recruit skeleton and move it to the lower right corner of the
map

There was an assertion failure:
wesnoth:
/home/matthias/vcs/github/wesnoth/src/whiteboard/side_actions.cpp:163:
wb::side_actions_container::iterator wb::side_actions_container::queue(size_t,
wb::action_ptr): Assertion `turn_num <= num_turns() || future_only' failed.







___

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