[Wesnoth-bugs] [task #8018] Data Export #74 (patch)

[Lari Nieminen]

URL:
  <http://gna.org/task/?8018>

 Summary: Data Export #74 (patch)
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Wed 03 May 2017 08:21:23 AM UTC
Category: None
 Should Start On: Wed 03 May 2017 12:00:00 AM UTC
   Should be Finished on: Thu 04 May 2017 12:00:00 AM UTC
Priority: 5 - Normal
  Status: None
 Privacy: Private
Percent Complete: 0%
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
  Effort: 0.00

___

Details:

A new export job has been registered.
 
This task has been created to keep the project informed. However, only Lari
Nieminen, that created the job, can remove the job itself. 

= Job URL =

Once the job will be done, it will be available at:

  <https://gna.org/export/wesnoth/zookeeper/74.xml>


= Job Removal  =

Closing this task will not remove the job. To remove the job, Lari Nieminen
must go at: 

  <https://gna.org/patch/export.php?group=wesnoth>


= Job Details =

The SQL query will be:
SELECT bug_id  FROM patch  WHERE group_id=\'1242\' 


(Note: We are aware this information is not tremendously user-friendly. This
will be improved in future Savane releases)





___

Reply to this item at:

  <http://gna.org/task/?8018>

___
  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] [task #8015] Data Export #71 (bugs)

[Lari Nieminen]

URL:
  <http://gna.org/task/?8015>

 Summary: Data Export #71 (bugs)
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Tue 02 May 2017 06:15:45 AM UTC
Category: None
 Should Start On: Tue 02 May 2017 12:00:00 AM UTC
   Should be Finished on: Wed 03 May 2017 12:00:00 AM UTC
Priority: 5 - Normal
  Status: None
 Privacy: Private
Percent Complete: 0%
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
  Effort: 0.00

___

Details:

A new export job has been registered.
 
This task has been created to keep the project informed. However, only Lari
Nieminen, that created the job, can remove the job itself. 

= Job URL =

Once the job will be done, it will be available at:

  <https://gna.org/export/wesnoth/zookeeper/71.xml>


= Job Removal  =

Closing this task will not remove the job. To remove the job, Lari Nieminen
must go at: 

  <https://gna.org/bugs/export.php?group=wesnoth>


= Job Details =

The SQL query will be:
SELECT bug_id  FROM bugs  WHERE group_id=\'1242\' 


(Note: We are aware this information is not tremendously user-friendly. This
will be improved in future Savane releases)





___

Reply to this item at:

  <http://gna.org/task/?8015>

___
  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 #25522] bad terrain transition

[Lari Nieminen]

Update of bug #25522 (project wesnoth):

  Status:   Confirmed => Fixed  

___

Follow-up Comment #3:

Should be fixed now (in 7a23c80b).

___

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 #25535] hex grid offset sometimes?

[Lari Nieminen]

Update of bug #25535 (project wesnoth):

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

___

Follow-up Comment #2:

Commit 9fc1e497e1ed should fix this by making the grid be drawn even on the
off-map hexes (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 #25217] unit moves on impassible terrain

[Lari Nieminen]

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

For some reason, the spawns are given some altered movement costs, which
specifically includes impassable=3. It seems to have always been that way,
although I don't know the exact reasoning, as it can certainly lead to
unpredictable weirdness like that and the back mountains/wall are the only
impassable terrains anyway.

So, while it's not a technical bug, I don't think it'd be inappropriate to
call it a bug in the scenario design... even if it's intentional.

___

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 #25535] hex grid offset sometimes?

[Lari Nieminen]

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

It's not a problem with offsetting as such, it just happens due to the way the
grid images are drawn; no images are drawn on the off-map edge hexes, which
leaves the lines at the bottom row very dark and faint, which leads them to be
almost invisible against a dark background like void/cavewall/etc.

However, it's of course a legit problem and it'd be great if it could be
fixed. Seeing how terrains draw correctly at the edges, it might not even be
particularly hard.

___

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 #25522] bad terrain transition

[Lari Nieminen]

Follow-up Comment #2, bug #25522 (project wesnoth):

No, it's new and caused by some of my terrain graphics rule changes.

___

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 #25522] bad terrain transition

[Lari Nieminen]

Update of bug #25522 (project wesnoth):

  Status:None => Confirmed  
 Assigned to:None => zookeeper  


___

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?

[Lari Nieminen]

Update of bug #25346 (project wesnoth):

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

___

Follow-up Comment #2:

The problem was that it is actually ~BRIGHTEN and it's simply always been
misdocumented as ~LIGHTEN. The wiki's been updated now, also with information
on how to actually use the functions, although both will be removed as of
1.13.7 because they're essentially useless.

___

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 #25496] HTTT: S18 - Is Delfador using the right portrait consistently?

[Lari Nieminen]

Follow-up Comment #2, bug #25496 (project wesnoth):

Yes, he switches out of his elvish clothes on his reappearance at the end of
Siege of Elensefar. If you skip that, he'll be stuck with them (except when
using the expression variants such as mentoring).


___

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] [task #8002] Data Export #58 (bugs)

[Lari Nieminen]

Update of task #8002 (project wesnoth):

   status_id: => Closed 

___

Follow-up Comment #0:

[100]
Job removed per request of his owner, Lari Nieminen 

58.xml is no longer available

___

Reply to this item at:

  <http://gna.org/task/?8002>

___
  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] [task #8002] Data Export #58 (bugs)

[Lari Nieminen]

URL:
  <http://gna.org/task/?8002>

 Summary: Data Export #58 (bugs)
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Wed 08 Feb 2017 07:53:57 AM UTC
Category: None
 Should Start On: Wed 08 Feb 2017 12:00:00 AM UTC
   Should be Finished on: Thu 09 Feb 2017 12:00:00 AM UTC
Priority: 5 - Normal
  Status: None
 Privacy: Private
Percent Complete: 0%
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
  Effort: 0.00

___

Details:

A new export job has been registered.
 
This task has been created to keep the project informed. However, only Lari
Nieminen, that created the job, can remove the job itself. 

= Job URL =

Once the job will be done, it will be available at:

  <https://gna.org/export/wesnoth/zookeeper/58.xml>


= Job Removal  =

Closing this task will not remove the job. To remove the job, Lari Nieminen
must go at: 

  <https://gna.org/bugs/export.php?group=wesnoth>


= Job Details =

The SQL query will be:
SELECT bug_id  FROM bugs  WHERE group_id=\'1242\' 


(Note: We are aware this information is not tremendously user-friendly. This
will be improved in future Savane releases)





___

Reply to this item at:

  <http://gna.org/task/?8002>

___
  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 #25471] [Sighted] event in TSG 07a_Into_the_Depths does not fire

[Lari Nieminen]

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

I can't reproduce this, although I've only tried with master and 1.13.5.

___

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 #25417] HttT: picked up sceptre with Li'sar, but Konrad got the new attack

[Lari Nieminen]

Update of bug #25417 (project wesnoth):

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

___

Follow-up Comment #1:

This was reported in IRC recently and fixed (in commit 43fd758dae).

I've attached a fixed version of the savefile, so if you want you can continue
playing from there and have Li'sar get the sceptre. 

P.S. Her sprite changing awkwardly when she gets the sceptre is a known issue.

(file #29638)
___

Additional Item Attachment:

File name: preLisarGet_fixed.gz   Size:83 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 #25397] Animations immediately following a message get truncated

[Lari Nieminen]

URL:
  

 Summary: Animations immediately following a message get
truncated
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Tue 20 Dec 2016 08:31:50 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
Operating System: win 7

___

Details:

If a [message] is shown right prior to an animation, then the animation gets
skipped or truncated somehow. It doesn't seem to matter whether the animation
is one triggered by [animate_unit] or for example a regular combat animation.
I'm also not entirely sure whether other things besides animations suffer from
the same problem.

One can workaround the problem by inserting a delay after the message (for
example even [delay] time=0 [/delay] works). So, one possible fix was to add
wesnoth.delay(1) to the [message] implementation, but vultraz didn't want that
because it'd cause a brief flicker between successive messages.

A simple test case:

[event]
name=attacker hits,attacker misses,defender hits,defender misses
first_time_only=no

{DEBUG_MSG "As long as this message is here, the following combat
animations won't play correctly"}
[/event]






___

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 #25311] UTBS(New units): Infinite Kalehs

[Lari Nieminen]

Update of bug #25311 (project wesnoth):

  Status:None => Fixed  

___

Follow-up Comment #2:

Sorry, I forgot to update this to say that it's actually already been fixed.

___

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

[Lari Nieminen]

Update of bug #25363 (project wesnoth):

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


___

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 #25311] UTBS(New units): Infinite Kalehs

[Lari Nieminen]

Update of bug #25311 (project wesnoth):

 Assigned to:None => zookeeper  


___

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 #18866] Beach images misaligned

[Lari Nieminen]

Update of bug #18866 (project wesnoth):

  Status:None => Fixed  
 Assigned to:None => zookeeper  
 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 #25131] [move_unit] check_passability=no doesn't work

[Lari Nieminen]

Update of bug #25131 (project wesnoth):

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


___

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

[Lari Nieminen]

Update of bug #25131 (project wesnoth):

 Release:   1.3.5+dev => 1.13.5+dev 

___

Follow-up Comment #2:

Oops, yes, that was a mistake.

___

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

[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

[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 #20783] Sometimes, clicking a terrain button after scrolling doesn't do anything

[Lari Nieminen]

Follow-up Comment #3, bug #20783 (project wesnoth):

This is different from bug #24501, but still valid.

___

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 #24501] Scrolling terrain palette with mousewheel scrolls map too

[Lari Nieminen]

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

Not a duplicate of bug #20783, it's a different (and still existing) problem.

___

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 #25019] [TIE] Gweddry gains (sometimes) no EP

[Lari Nieminen]

Update of bug #25019 (project wesnoth):

  Status:None => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

Yes, XP from (non-lethal) combat is 1 XP per enemy level, and thus fighting
but not killing Vampire Bats gives you no XP.

___

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 #22516] [standard_unit_filter] id = "" behaviour changed

[Lari Nieminen]

Update of bug #22516 (project wesnoth):

  Status:None => Confirmed  

___

Follow-up Comment #2:

This still seems to be an issue.

___

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 #24954] Eastern Invasion: Outlaws won't appear in 05_Northern Outpost

[Lari Nieminen]

Update of bug #24954 (project wesnoth):

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

___

Follow-up Comment #3:

Thanks, it's fixed now.

If you want to finish the scenario without just skipping it with debug mode,
there's a few alternatives you can try mentioned at
https://forums.wesnoth.org/viewtopic.php?f=4=5

___

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}

[Lari Nieminen]

Update of bug #24853 (project wesnoth):

  Status:None => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

While the macro definitions can stay for compatibility's sake, it's true that
their contents should probably be removed, so that UMC animations still using
those macros don't cause the sounds to be played twice.

___

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}

[Lari Nieminen]

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

The sounds for slow/poison/petrify are now played automatically irrespective
of animations, which is why the uses of {SOUND:SLOW} have been removed from
animations. Is there an actual problem with the sounds not playing when they
should?

___

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 #23901] an [escape] tag in [message]

[Lari Nieminen]

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

I'd think it'd be better to add an optional key with which to mark one
[option] as the "escape/quit/exit/dismiss" option, which would then be chosen
if the player presses esc (which would do nothing if none of the options have
that key).

If someone wants the player to be able to basically ignore the presented list
of options, then they should add that possibility to the list itself in the
first place.

___

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 #24683] Host cannot take control of an idle side

[Lari Nieminen]

URL:
  

 Summary: Host cannot take control of an idle side
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Wed 18 May 2016 10:13:36 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.4+dev
Operating System: win7

___

Details:

If a player leaves and the host chooses "Set side to idle", then they cannot
directly take control of that side again; using ":control 
" results in nothing at all happening. They can assign control
to another player though, and back to themselves after that.

Likely it's because the host is already considered to be in control of that
side.




___

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 #24681] Documentation update for command mode key

[Lari Nieminen]

URL:
  

 Summary: Documentation update for command mode key
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Wed 18 May 2016 09:55:40 AM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: aginor
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.4+dev
Operating System: all

___

Details:

Since the command mode key might be something other than : on non-US
keyboards, the documentation in various places[1] needs to be changed
accordingly.

[1] At least the in-game help, CommandMode wiki page and the manual.




___

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 #24672] Leadership ability does not work when applied as an object

[Lari Nieminen]

Update of bug #24672 (project wesnoth):

 Assigned to:None => celticminstrel 

___

Follow-up Comment #1:

Assigning to celticminstrel, as this sounds most likely to be due to variable
substitution of $other_unit in the new implementation.

___

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 #24644] Units moving after in game help exit

[Lari Nieminen]

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

It's enough to just select a unit, open the help by clicking on a
trait/ability/race/type/alignment in the sidebar, and then close the help
(whether via the button or esc).

___

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 #24633] AI stops performing gotos if one fails

[Lari Nieminen]

URL:
  

 Summary: AI stops performing gotos if one fails
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Mon 02 May 2016 01:20:26 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Artificial Intelligence
  Status: None
 Privacy: Public
 Assigned to: mattsc
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.4+dev
Operating System: win7

___

Details:

If several AI units have goto_x,goto_y set and one of them is unreachable (for
example, because another unit is standing on it), the gotos of other remaining
units (which would normally be performed next) are not executed.

In other words, if a goto fails, then the whole goto process seems to exit
early.

Reported in https://forums.wesnoth.org/viewtopic.php?p=596735#p596735 (I can
provide a more convenient savefile for testing and/or test the fixes myself)

As in the report, this affects 1.12 as well, and I'm not sure when exactly the
bug has been introduced or whether it's always existed. I suspected commit
fddc2873 but couldn't confirm.




___

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 #24583] Resolution locked in fullscreen mode

[Lari Nieminen]

URL:
  

 Summary: Resolution locked in fullscreen mode
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Tue 12 Apr 2016 11:12:08 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Graphics
  Status: Confirmed
 Privacy: Public
 Assigned to: aginor
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.4
Operating System: all

___

Details:

Choosing resolution even in fullscreen mode should be made possible 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 #24366] Water maps slow on 1.13.2+dev

[Lari Nieminen]

Update of bug #24366 (project wesnoth):

 Assigned to:   zookeeper => aginor 

___

Follow-up Comment #6:

I've now done pretty much all I can regarding optimization of the
water-related terrain graphics rules, so further performance improvements will
have to come from the engine side.

___

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 #15304] Race description tooltip in the right-side panel

[Lari Nieminen]

Update of bug #15304 (project wesnoth):

  Status:None => Wont Fix   
 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 #23161] Assert from synced_context.cpp when closing the game

[Lari Nieminen]

Update of bug #23161 (project wesnoth):

  Status:None => 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 #5821] Moving unit_height_adjust from [terrain] to [tile]

[Lari Nieminen]

Update of bug #5821 (project wesnoth):

 Assigned to:mordante => zookeeper  


___

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 #24517] Load map dialog should have shortcut to game data

[Lari Nieminen]

URL:
  

 Summary: Load map dialog should have shortcut to game data
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Sun 13 Mar 2016 10:07:40 AM UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Editor
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.4+dev
Operating System: win7

___

Details:

It's very tedious to navigate to the game data directory in the editor, on
Windows requiring as many as 6 steps just to get down to the root directory,
after which you still have to navigate back up to the installation directory,
the location of which you might not even remember.

The "load map" dialog (and probably "save map" as well) should have a shortcut
button (or two) to teleport you between the game data and userdata
directories.




___

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 #24314] Drawing and sheathing animations lack ellipses

[Lari Nieminen]

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

Same also applies to healing, healed and poisoned animations. While not combat
animations, I see no reason why ellipses should turn off during them.

___

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 #24501] Scrolling terrain palette with mousewheel scrolls map too

[Lari Nieminen]

URL:
  

 Summary: Scrolling terrain palette with mousewheel scrolls
map too
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Sun 06 Mar 2016 11:24:18 AM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Editor
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.3+dev
Operating System: win7

___

Details:

In the editor, if you mouseover the terrain palette and use the mousewheel to
scroll up and down, it causes the map to scroll up and down 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 #24500] [filter] doesnt filter the traits.. why?

[Lari Nieminen]

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

[filter_wml] is presumably the slowest one, but that's not a problem unless
it's *too* slow.

___

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 #24439] Crash on load mp replays with all AI players; most replays crash on stop/reset

[Lari Nieminen]

Update of bug #24439 (project wesnoth):

 Assigned to:   zookeeper => None   

___

Follow-up Comment #8:

This should fix the unit_creator crash, so I'm unassigning this from myself:
https://github.com/wesnoth/wesnoth/commit/f4cb6569211316d496e6896d595e5f66da1f15e1

___

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 #24439] Can't load multiplayer replays

[Lari Nieminen]

Update of bug #24439 (project wesnoth):

 Assigned to:None => zookeeper  


___

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 #24366] Water maps slow on 1.13.2+dev

[Lari Nieminen]

Update of bug #24366 (project wesnoth):

  Status:None => In Progress

___

Follow-up Comment #5:

df9cecd5

should decrease memory use back to acceptable levels, although it might
slightly increase CPU use (which is something that needs to be mitigated in
other ways).

___

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 #24366] Water maps slow on 1.13.2+dev

[Lari Nieminen]

Update of bug #24366 (project wesnoth):

 Assigned to:None => zookeeper  

___

Follow-up Comment #3:

Peaking at >700MB on a single-terrain 200x200 map like that sounds weird,
since I only see <300MB in that case (even after scrolling around everywhere).
You sure that wasn't affected by other maps you had open(ed)?

Anyway, the biggest problem is the transitions. I'll do some optimization
there and see how much that helps. In the meantime, it wouldn't hurt to hear
what your performance and memory use are like if you disable all the water
transitions by removing these lines:

https://github.com/wesnoth/wesnoth/blob/master/data/core/terrain-graphics.cfg#L844-L858

For what it's worth, I'm still on SDL1.

___

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 #24314] Drawing and sheathing animations lack ellipses

[Lari Nieminen]

URL:
  

 Summary: Drawing and sheathing animations lack ellipses
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Fri 15 Jan 2016 10:47:16 PM UTC
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group: Graphics
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.2+dev
Operating System: win

___

Details:

Unit ellipses are drawn during all other combat animations, but not during
draw_weapon and sheath_weapon animations.

Sky Drake, Hurricane Drake and Merman Hunter are easy core testcases.




___

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 #23712] Mage of Light halo not drawing correctly

[Lari Nieminen]

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

No, for me the adept's halo is bugged as well. It shows up fine at scenario
start, but when I move the unit around it flickers on and off and in the top
left corner just like the MoL's halo.

___

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 #23712] Mage of Light halo not drawing correctly

[Lari Nieminen]

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

I did some testing:

Even for example the Autumn Shyde in TRoW has the same problem. However, its
halo is animated, meaning that it gets redrawn constantly and for some reason
that helps to mostly keep it where it should be. Also, its halo is faint
enough that it's not really noticeable when it flickers off.

Wose Shamans in DM didn't seem to have the problem, and that's probably
because the halo is for some reason part of their standing animation instead.

Making the MoL halo animated will help slightly by causing redraws more often,
for example with:
halo=halo/illuminates-aura.pn[g*10]:50

It doesn't seem to have anything to do with the halo size.

I'm not sure exactly when the halo gets misdrawn, but it happens consistently
at least during movement.

___

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 #24226] Multiplayer player name displayed in singleplayer

[Lari Nieminen]

URL:
  

 Summary: Multiplayer player name displayed in singleplayer
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Thu 24 Dec 2015 10:17:40 AM 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.2+dev
Operating System: win

___

Details:

In singleplayer campaigns, the tooltip of the turn counter as well as the
title of the statistics dialog show the player's name (from multiplayer)
instead of the leader's name as it should (as in 1.12).

The player name is also shown in the "More >" part of the status table, but
I'm not 100% sure whether that's intentional or not.




___

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 #23712] Mage of Light halo not drawing correctly

[Lari Nieminen]

Follow-up Comment #2, bug #23712 (project wesnoth):

As of now, the halo seems to only be drawn in the top left corner of the
screen, never on the unit.

___

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 #23024] ghazi plays the slow sound even when missing the shield bash

[Lari Nieminen]

Update of bug #23024 (project wesnoth):

  Item Group: Multiplayer => Sound and music
  Status: In Progress => Fixed  

___

Follow-up Comment #4:

This should now be fixed in 1.13. Unlikely to get backported to 1.12 as it
involves changes to all animations using slow/poison sounds, and would thus
cause UMC units to play sounds double if their animations are not updated, or
to not play the sounds at all if their animations are not updated but 1.12.4
or earlier is used.

___

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 #23065] [music] unable to replace playlist without interrupting current track

[Lari Nieminen]

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

To clarify, the fix is fine in master.

In 1.12, the previously mentioned change to behavior of scenario-level [music]
tags causes a slight compatibility break so it should be addressed somehow; if
it's possible to re-port to 1.12 with an added check for whether the [music]
tag is scenario-level or not, that'd do.

In other words, in 1.12, a plain scenario-level [music] tag should default to
immediate=yes.

___

Reply to this item at:

  http://gna.org/bugs/?23065

___
  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 #23161] Assert from synced_context.cpp when closing the game

[Lari Nieminen]

Follow-up Comment #2, bug #23161 (project wesnoth):

Well, as far as I can tell it's possible that closing of the game had nothing
to do with it and it just happened to perfectly coincide with it.

___

Reply to this item at:

  http://gna.org/bugs/?23161

___
  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 #23161] Assert from synced_context.cpp when closing the game

[Lari Nieminen]

URL:
  http://gna.org/bugs/?23161

 Summary: Assert from synced_context.cpp when closing the game
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Sat 10 Jan 2015 12:15:32 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.12.0
Operating System: win7

___

Details:

File: src\synced_context.cpp
Line: 39
Expression: use_undo || (!resources::undo_stack-can_redo() 
!resources::undo_stack-can_undo())

I failed to reproduce this a second time, but this is what I did the first
time it occurred:

1. Networked 2p multiplayer with two clients (both running 1.12.0).
2. Side/client 2 quit the game (by closing the app).
3. I chose replace with ai on client 1 and immediately afterwards closed the
app (via the top-right X), at which point the assert happened.

I had been making moves and messing with Delay Shroud Updates in all sorts of
ways on both clients, which is probably relevant.




___

Reply to this item at:

  http://gna.org/bugs/?23161

___
  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 #23117] Invert breaks lobby filtering if Apply Filter is off

[Lari Nieminen]

URL:
  http://gna.org/bugs/?23117

 Summary: Invert breaks lobby filtering if Apply Filter is
off
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Sat 27 Dec 2014 03:57:34 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.12.0
Operating System: win7

___

Details:

In the (non-experimental) multiplayer lobby, if you have the Invert filter
checkbox ticked when you detick the Apply Filter checkbox, you will see no
games at all (as opposed to what should happen: seeing all of them).




___

Reply to this item at:

  http://gna.org/bugs/?23117

___
  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 #23103] [unstore_unit] with check_passability=yes does not place the unit if there is no suitable place

[Lari Nieminen]

Follow-up Comment #2, bug #23103 (project wesnoth):

It indeed seems like a corner case that the WML author should take into
consideration.

However, it *could* be smarter and simply ignore check_passability if there
aren't (or can't be) *any* passable locations on the whole map and just place
the unit where it was told to (still respecting find_vacant, of course) and
write a note about it to the log.

___

Reply to this item at:

  http://gna.org/bugs/?23103

___
  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 #23059] SG: Vengeance - message using name doesn't display

[Lari Nieminen]

Update of bug #23059 (project wesnoth):

  Status:None = Fixed  
 Assigned to:None = zookeeper  


___

Reply to this item at:

  http://gna.org/bugs/?23059

___
  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 #23053] EI: Captured ignores difficulty levels

[Lari Nieminen]

Update of bug #23053 (project wesnoth):

  Status:None = Fixed  
 Assigned to:None = zookeeper  

___

Follow-up Comment #1:

Fixed in 533cf432be13 and 3c60833fb113. Hard remains as it was, while on
normal some of the troll guards are dropped to lvl2, and on easy all of them
are lvl2.

___

Reply to this item at:

  http://gna.org/bugs/?23053

___
  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 #23065] [music] unable to replace playlist without interrupting current track

[Lari Nieminen]

URL:
  http://gna.org/bugs/?23065

 Summary: [music] unable to replace playlist without
interrupting current track
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Fri 12 Dec 2014 11:30:11 PM UTC
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group: Sound and music
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.12.0
Operating System: win7

___

Details:

It should be possible to change the playlist without interrupting the current
track by using immediate,append=no,no. Currently, doing so does cause an
immediate switch to the new playlist.

Here, the playlist switch upon the first move should allow elf-land to finish
playing first, but currently doesn't (instead, the switch happens as if
immediate=yes was used):


[event]
name=start

[music]
name=elf-land.ogg
immediate=yes
append=no
[/music]
[/event]
[event]
name=moveto

[music]
name=defeat.ogg
immediate=no
append=no
[/music]
[/event]





___

Reply to this item at:

  http://gna.org/bugs/?23065

___
  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 #23048] EI: Evacuation - ill-formed terrain modification causes horizontal line

[Lari Nieminen]

Update of bug #23048 (project wesnoth):

  Status:None = Fixed  
 Assigned to:None = zookeeper  


___

Reply to this item at:

  http://gna.org/bugs/?23048

___
  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 #23024] ghazi plays the slow sound even when missing the shield bash

[Lari Nieminen]

Update of bug #23024 (project wesnoth):

  Status:   Fixed = In Progress
 Assigned to:  wintermute = zookeeper  

___

Follow-up Comment #3:

Actually it's not fixed after all, apparently my testing was faulty. I'll see
if I can come up with a proper fix, since the same issue ought to affect other
units as well.

___

Reply to this item at:

  http://gna.org/bugs/?23024

___
  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 #23023] Broken terrain description for oasis

[Lari Nieminen]

URL:
  http://gna.org/bugs/?23023

 Summary: Broken terrain description for oasis
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Wed 03 Dec 2014 08:38:23 PM UTC
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: fendrin
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.12.0
Operating System: win7

___

Details:

Checking Terrain Description for an oasis from the right-click menu only
brings up a page titled Desert Sands /.




___

Reply to this item at:

  http://gna.org/bugs/?23023

___
  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 #23024] ghazi plays the slow sound even when missing the shield bash

[Lari Nieminen]

Update of bug #23024 (project wesnoth):

  Status:None = Fixed  

___

Follow-up Comment #1:

Should be fixed now.

___

Reply to this item at:

  http://gna.org/bugs/?23024

___
  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 #22945] Poison stopping/curing explanation slightly confusing

[Lari Nieminen]

URL:
  http://gna.org/bugs/?22945

 Summary: Poison stopping/curing explanation slightly
confusing
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Tue 11 Nov 2014 11:02:36 PM UTC
Category: Feature Request
Severity: 1 - Wish
Priority: 3 - Low
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13
Operating System: all

___

Details:

Description for the heals abilities states this:

A poisoned unit cannot be cured of its poison by a healer, and must seek the
care of a village or a unit that can cure.

It's somewhat confusing, because a healer would commonly be understood to
mean a unit which has the heals ability, many of which can in fact also cure
poison. It'd be good to make the description less ambiguous by referring to
the limitations of the ability, not the unit.




___

Reply to this item at:

  http://gna.org/bugs/?22945

___
  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 #22866] Indeterministic character portraits in Heir to the Throne

[Lari Nieminen]

Follow-up Comment #2, bug #22866 (project wesnoth):

It was apparently an oversight that the tutorial portraits were forgotten when
the new HttT portraits were added in 1.10.7. This was fixed ages ago in 1.11
and there won't be further 1.10 releases, so the obsolete portraits problem
can be considered either as fixed or won't fix now, I suppose.

The issue of images leaking from the tutorial to a campaign (or similarly from
one campaign to another, probably?) sounds like a bug however, so I'm leaving
the report open for that.

___

Reply to this item at:

  http://gna.org/bugs/?22866

___
  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 #22790] UtBS - dehydration/thirst effect buggy

[Lari Nieminen]

Update of bug #22790 (project wesnoth):

  Status:None = Fixed  
 Assigned to:alarantalara = zookeeper  

___

Follow-up Comment #2:

I think these ought to all be fixed now. The dehydration logic for enemy units
could still be improved on, but at least now all the ogres and humans that the
player can see ought to receive dehydration normally.

___

Reply to this item at:

  http://gna.org/bugs/?22790

___
  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 #22837] Illumination circles are not being drawn

[Lari Nieminen]

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

Mage of Light and Mermaid Diviner both have the halo as they should.

___

Reply to this item at:

  http://gna.org/bugs/?22837

___
  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 #22799] UtBS - A Subterranean Struggle - Dwarf Grenadiers do not kill any trolls

[Lari Nieminen]

Update of bug #22799 (project wesnoth):

  Status:None = Fixed  
 Assigned to:None = zookeeper  

___

Follow-up Comment #1:

Should be fixed now.

___

Reply to this item at:

  http://gna.org/bugs/?22799

___
  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 #22800] UtBS - A Subterranean Struggle - Cloaked Figure appears in strange location

[Lari Nieminen]

Update of bug #22800 (project wesnoth):

  Status:None = Fixed  
 Assigned to:None = zookeeper  


___

Reply to this item at:

  http://gna.org/bugs/?22800

___
  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 #22466] Heir to the Throne - Home of the North Elves - dialogue in wrong place

[Lari Nieminen]

Follow-up Comment #3, bug #22466 (project wesnoth):

Having spent a bit of time looking at usage in mainline, it seems there's a
bunch of sighted events which assume that AI sides without fog/shroud won't
cause them to trigger. Of course, those would be straightforward to fix by
adding the secondary filters.

On one hand, the current way is brutally consistent, but then again it
probably causes a little bit of confusion and breaks a lot of old events which
would otherwise now function as intended. However, there's certainly some
value in allowing unfogged/unshrouded sides to sight units as they're for
example recruited. It sounds like one couldn't really fix the problem as it
appears in this scenario without removing the ability to do that, right?

I don't think the possibility of using sighted events as a way to detect when
a unit appears on an unfogged/unshrouded map is important enough to influence
the decision, though.

___

Reply to this item at:

  http://gna.org/bugs/?22466

___
  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 #22487] Advanced preference description not showing up

[Lari Nieminen]

URL:
  http://gna.org/bugs/?22487

 Summary: Advanced preference description not showing up
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Sat 16 Aug 2014 08:11:55 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.11.16
Operating System: win 7

___

Details:

In the advanced preferences, the help text at the bottom of the screen repeats
the name of the hovered-over preference, whereas it should display its
description instead.

The name and description parsing code in preferences_dialog::process_event()
looks correct, however.




___

Reply to this item at:

  http://gna.org/bugs/?22487

___
  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 #22466] Heir to the Throne - Home of the North Elves - dialogue in wrong place

[Lari Nieminen]

Update of bug #22466 (project wesnoth):

 Assigned to:None = jamit  

___

Follow-up Comment #1:

This ought to be due to the fixes to sighted events; sighted events (with a
filter only for the primary unit) now trigger at scenario start if there is a
side without fog/shroud, because that side always sees the primary unit unless
it's ambushing.

I'm not absolutely sure if it should work like that, that is whether sighted
events should fire at scenario start if side X sees the primary unit simply by
virtue of not having fog/shroud in the first place. I'd think it'd be more
intuitive if a sighted event would only trigger if the sighted unit has
actually been out of sight previously, but maybe there is a reason for it.

I'll assign to Jamit so he gets notified and can comment. If it's now working
as intended, then I can fix the WML accordingly.

___

Reply to this item at:

  http://gna.org/bugs/?22466

___
  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 #22379] Tops of buttons in statistics dialog cut off

[Lari Nieminen]

URL:
  http://gna.org/bugs/?22379

 Summary: Tops of buttons in statistics dialog cut off
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Tue 22 Jul 2014 09:39:59 AM UTC
Category: Bug
Severity: 2 - Minor
Priority: 3 - Low
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.11.16
Operating System: win 7

___

Details:

The tops of the Select Scenario and Details buttons in the statistics
dialog are cut off depending on which item has last had the focus. Looks like
an off-by-one mistake in positioning of the elements.



___

File Attachments:


---
Date: Tue 22 Jul 2014 09:39:59 AM UTC  Name: stats_button_overlap.jpg  Size:
70kB   By: zookeeper

http://gna.org/bugs/download.php?file_id=21505

___

Reply to this item at:

  http://gna.org/bugs/?22379

___
  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 #22382] Restore whitespace-aligned columns in map format

[Lari Nieminen]

URL:
  http://gna.org/bugs/?22382

 Summary: Restore whitespace-aligned columns in map format
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Tue 22 Jul 2014 02:00:09 PM UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: alarantalara
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.11
Operating System: all

___

Details:

In ea3028 (see also 7f5f62 and possibly also 1a27a8), the old method of
aligning up the columns in map data with spaces was dropped. This makes
reading and editing of plain map data a lot harder for no apparent tangible
benefit.

The old way padded each entry to a length of 12 (excluding the preceding
space):


Gs^Fms  , Gs^Fp   , Gg  , Gg
Wo  , Wo  , Ur  , Cud


The new format only includes the preceding space:


Gs^Fms, Gs^Fp, Gg, Gg
Wo, Wo, Ur, Cud


So, I'd suggest restoring the old padding behavior, although the number of
spaces could be reduced if necessary; since a terrain string cannot be longer
than 9 characters, the column width could be reduced from 12 to 9. As
future-proofing, the code should probably handle even longer strings
gracefully, or to signal an error if one is encountered.

P.S. Alarantalara made the change, so I'm assigning to him initially just so
he gets notified, in case he has input.




___

Reply to this item at:

  http://gna.org/bugs/?22382

___
  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 #22254] Map shows multiple journeys to the Elven Council in the Heir to the Throne campaign

[Lari Nieminen]

Update of bug #22254 (project wesnoth):

  Status:None = Fixed  
 Assigned to:None = zookeeper  
 Open/Closed:Open = Closed 

___

Follow-up Comment #1:

Fixed, but closing the report immediately since a 1.10.8 release is
unlikely...

___

Reply to this item at:

  http://gna.org/bugs/?22254

___
  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 #22242] UMC syntax errors not showing up

[Lari Nieminen]

Additional Item Attachment, bug #22242 (project wesnoth):

File name: Bug_Test.zip   Size:2 KB


___

Reply to this item at:

  http://gna.org/bugs/?22242

___
  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 #22242] UMC syntax errors not showing up

[Lari Nieminen]

URL:
  http://gna.org/bugs/?22242

 Summary: UMC syntax errors not showing up
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Sat 28 Jun 2014 05:43:40 PM UTC
Category: Bug
Severity: 4 - Important
Priority: 5 - Normal
  Item Group: WML
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.11.15
Operating System: win 7

___

Details:

If an add-on contains certain kinds (?) of syntax errors, they will not cause
an error dialog to pop up at loading time, and will only be listed in stderr.
Furthermore, because of the error the game will still make a mess of some
things internally, leading to completely unrelated false positives to
potentially appear.

Attached is an example campaign where the actual syntax error
(Bug_Test/scenario.cfg:22) isn't being reported in an error dialog, but a
completely unrelated false positive unknown unit type error pops up
instead.

I haven't been able to reproduce the problem with mainline campaigns; it seems
this only happens in add-ons. I also haven't tried to narrow down which kinds
of syntax errors are affected.




___

Reply to this item at:

  http://gna.org/bugs/?22242

___
  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 #22030] [disable] weapon special broken

[Lari Nieminen]

URL:
  http://gna.org/bugs/?22030

 Summary: [disable] weapon special broken
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Sat 10 May 2014 09:37:17 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.11.13
Operating System: all

___

Details:

The attack dialog doesn't correctly account for attacks disabled with the
[disable] special; if for example a unit's first attack is [disable]d,
choosing the remaining second attack in the attack dialog results in the first
attack (which is supposed to be disabled) to be used. Disabling the unit's
second attack instead (assuming the unit only has two attacks) works
correctly.




___

Reply to this item at:

  http://gna.org/bugs/?22030

___
  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 #8813] Allow filtering for valid/invalid targets in [attack]

[Lari Nieminen]

Update of bug #8813 (project wesnoth):

  Status:None = Fixed  
 Open/Closed:Open = Closed 

___

Follow-up Comment #1:

Fulfilled by the addition of the [disable] weapon special.

___

Reply to this item at:

  http://gna.org/bugs/?8813

___
  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 #20435] New drawing logic for maps in title and story screens

[Lari Nieminen]

URL:
  http://gna.org/bugs/?20435

 Summary: New drawing logic for maps in title and story
screens
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Mon 14 Jan 2013 10:55:23 AM GMT
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: trunk
Operating System: all

___

Details:

Scaling maps to fill the screen is ugly, so the new maps
http://forums.wesnoth.org/viewtopic.php?f=18t=38186 feature a tileable
background on which they may be drawn to eliminate the need for scaling the
map itself in most cases. Some engine support is needed to make it work,
though.

This is how the maps are intended to be drawn, both in the title screen as
well as story screens:

Background:

1. Scaled (preserving aspect ratio) so that it fills the window in the
vertical dimension.
2. Centered horizontally.
3. Tiled horizontally to both left and right, if window width is greater than
the image width after the scaling done in step 1.

Map:

1. Downscaled (preserving aspect ratio) so that it fills the window in the
vertical dimension, if the image height is greater than the window height.
2. If the window height exceeds 1440px, the map should be upscaled by
multiplying its dimensions by (windowheight / 1440).
3. Centered both horizontally and vertically.

I have no specific suggestion for how this should be implemented WML-wise. One
possibility might be to add all the required functionality to [part] and
[image], and then allow the title screen to be defined using those same tags.

For testing purposes, the background image can be found at
https://dl.dropbox.com/u/63964618/wesnoth/maps/wood_final.png




___

Reply to this item at:

  http://gna.org/bugs/?20435

___
  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 #20245] Status table scenario settings shows leader id's

[Lari Nieminen]

URL:
  http://gna.org/bugs/?20245

 Summary: Status table scenario settings shows leader id's
 Project: Battle for Wesnoth
Submitted by: zookeeper
Submitted on: Wed 17 Oct 2012 08:05:41 PM GMT
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: trunk
Operating System: all

___

Details:

When viewing scenario settings in the status table (via the More 
button), the leaders' id's are shown instead of their names, whereas unit it's
should not be player-visible anywhere.

The comments in #12050 seem to indicate that this is done for purposes of
showing the player names in MP, which makes sense, but it should only be done
for human-controlled sides in MP, not for AI-controlled sides even in MP nor
for anyone in SP campaigns.




___

Reply to this item at:

  http://gna.org/bugs/?20245

___
  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 #19685] Request for a [detect] ability

[Lari Nieminen]

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

I don't really see any problem with an ability like that. I might be more
inclined to propose adding an extra [filter_radius] filter however, to allow
better control of the detection paths.

I'd keep it simple and make it so that the detect ability always reveals any
units which match the given filters within the given radius, regardless of how
many and what kind of hides abilities they have.

One remaining question I think hasn't been addressed so far is whether the
owner of the detected unit would see their unit as having been detected; in
other words, does the ability prevent the hides ability from working at all,
or does it only allow the detecting side (and them only) to see through the
hides ability? It has quite some gameplay implications especially when fog is
used, or when there's multiple teams.

___

Reply to this item at:

  http://gna.org/bugs/?19685

___
  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 #19249] Internationalization improvement in Eastern Invasion — Two Paths

[Lari Nieminen]

Update of bug #19249 (project wesnoth):

  Item Group:Campaign = Translations   

___

Follow-up Comment #1:

Well, the strings were made separate precisely so that the exact mark-up for
whispers and thinking-to-oneself messages wouldn't need to be included in the
strings themselves, but could be defined in one centralized location; the
ASIDE macro in data/core/macros/interface-utils.cfg, in this case.

So, I'd think that what we need is to make the strings in those macros
translatable so translators could vary the exact formatting somewhat (although
of course then they'd need to make sure all affected strings in all campaigns
conform to that choice).

___

Reply to this item at:

  http://gna.org/bugs/?19249

___
  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 #19927] The Saurian Treasury missing (Village)

[Lari Nieminen]

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

Technically, it's correct, as swamp and water villages are not aliases of the
village terrain as far as movement and defense are concerned. A village which
is marked as being (Hills,Village) will give units their defense rating on
hills if it's higher than their defense rating on village, or their defense
rating on village if it's higher than their defense rating on hills, whereas
in a swamp or water village everyone simply uses their defense rating on swamp
or water.

___

Reply to this item at:

  http://gna.org/bugs/?19927

___
  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 #19334] ON_SIGHTING macro too often blocking undo

[Lari Nieminen]

Update of bug #19334 (project wesnoth):

  Status:None = Fixed  
 Assigned to:None = zookeeper  


___

Reply to this item at:

  http://gna.org/bugs/?19334

___
  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] [patch #2851] Patch for bug #17527: Feeding ability doubles when ghast and necrophage are in same scenario

[Lari Nieminen]

Update of patch #2851 (project wesnoth):

 Assigned to:   zookeeper = thonsew


___

Reply to this item at:

  http://gna.org/patch/?2851

___
  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 #18483] Implement duration= for [message]

[Lari Nieminen]

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

Note that the value should really be in milliseconds instead of frames.

___

Reply to this item at:

  http://gna.org/bugs/?18483

___
  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] [patch #2851] Patch for bug #17527: Feeding ability doubles when ghast and necrophage are in same scenario

[Lari Nieminen]

Follow-up Comment #16, patch #2851 (project wesnoth):

Since there seemed to have been a bit of confusion about, so I'll just try to
clarify the whole issue a bit:

The problem with feeding doubling is that both the Ghast and Necrophage
implement feeding using an identical event. The event dictates that whenever a
unit with feeding kills another, it gains 1HP. However, if both a Ghast and a
Necrophage appear in the same scenario, then both events are active (even
though they're identical), leading to any feeder who kills another unit to
gain 1HP from the first event and then another 1HP from the other event. This
could be fixed using an event filter, so that the feeding event for
Necrophages would only trigger when a Necrophage kills a unit, and the feeding
event for Ghast would only trigger when a Ghast kills a unit: the only reason
that's not an ideal fix is because it forces one to specify the unit type
whenever and wherever the feeding ability macro is called.

So, being able to give an event an id solves the problem by allowing both the
Necrophage and Ghast keep an identical copy of of the feeding event without
the game triggering both events when a feeder kills a unit, because the id
tells the game that they're the same event and that it shouldn't be duplicated
no matter how many times it appears in different places. Also, duplicate
events have legitimate uses, so making the game automatically detect identical
events and treat them in a special way would be a bad idea, and that's why we
need an explicit id attribute.

___

Reply to this item at:

  http://gna.org/patch/?2851

___
  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 #18355] EI: Owaec: WEAPON_SPECIAL_SHOCK doesn't work

[Lari Nieminen]

Update of bug #18355 (project wesnoth):

  Status:None = Fixed  
 Assigned to:None = zookeeper  

___

Follow-up Comment #2:

Fixed in r50524.

___

Reply to this item at:

  http://gna.org/bugs/?18355

___
  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 #17527] Feeding ability doubles when ghast and necrophage are in same scenario

[Lari Nieminen]

Update of bug #17527 (project wesnoth):

  Status:None = In Progress

___

Follow-up Comment #3:

I'm marking this In Progress because the fix shouldn't be considered
final.

Still, for most practical purposes it should now work correctly. The only
exceptions are situations in which a unit dies in the hands of a feeder, is
stored by an unrelated event and unstored back later and dies again in the
hands of a feeder on the same turn number as previously (regardless of whether
it's the same scenario or not); in those situations feeding would not activate
at all for the second kill. This would be most likely to happen as a result of
another WML-driven ability using such a store/unstore mechanism.

___

Reply to this item at:

  http://gna.org/bugs/?17527

___
  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 #18059] deep water terrain contrast with shallow water is insufficient

[Lari Nieminen]

Update of bug #18059 (project wesnoth):

 Assigned to:None = eleazar

___

Follow-up Comment #2:

Can you be more specific? There's three versions (gray, normal, tropical) of
both shallow and deep water, and not all combinations are difficult to tell
apart. If you don't know which one of those three you're looking at then you
can just name the map in which they appear, too.

Also, the time of day colour-shifting likely affects it as well, making
things harder to distinquish at night and so on.

___

Reply to this item at:

  http://gna.org/bugs/?18059

___
  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] [patch #2596] bug #17921: In the South Guard, The Long March the secret path is not revealed

[Lari Nieminen]

Update of patch #2596 (project wesnoth):

  Status:None = Done   


___

Reply to this item at:

  http://gna.org/patch/?2596

___
  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 #17922] RANDOM_SIDE macro not working

[Lari Nieminen]

Update of bug #17922 (project wesnoth):

  Status:None = Invalid
 Assigned to:None = zookeeper  
 Open/Closed:Open = Closed 

___

Follow-up Comment #2:

Agreed, it's not a bug. Calls to undefined macros are ignored in 1.8 whereas
in 1.9 they produce visible errors, which is why it seems to work on 1.8
(until you start looking for the missing random side entry in the faction
list...).

___

Reply to this item at:

  http://gna.org/bugs/?17922

___
  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 #17671] TRoW Temple of the Deep corpses spawn in cave wall

[Lari Nieminen]

Update of bug #17671 (project wesnoth):

  Status:None = Fixed  
 Assigned to:None = zookeeper  


___

Reply to this item at:

  http://gna.org/bugs/?17671

___
  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 #17388] Missing Graphics on the mission Giving Some Back

[Lari Nieminen]

Update of bug #17388 (project wesnoth):

  Status:None = Fixed  
 Assigned to:None = zookeeper  


___

Reply to this item at:

  http://gna.org/bugs/?17388

___
  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 #17368] setting side_for= breaks messages with options

[Lari Nieminen]

Update of bug #17368 (project wesnoth):

 Assigned to:None = silene 


___

Reply to this item at:

  http://gna.org/bugs/?17368

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


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