[Wesnoth-bugs] [bug #14503] Player often can't see his own shadows and nightgaunts

[Dan Gerhards]

Follow-up Comment #29, bug #14503 (project wesnoth):

No, that's good. Thanks for working on this!

___

Reply to this item at:

  

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


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

[Wesnoth-bugs] [bug #14503] Player often can't see his own shadows and nightgaunts

[Dan Gerhards]

Follow-up Comment #26, bug #14503 (project wesnoth):

Okay, great!

You posted the relevant lines in this thread on March 20. I just changed the
two instances of 0.5 to 0.6.

___

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 #14503] Player often can't see his own shadows and nightgaunts

[Dan Gerhards]

Follow-up Comment #24, bug #14503 (project wesnoth):

All right. I just didn't want to potentially have to go through this again
with the nightgaunt.

I can't think of any problem this could cause, and 1.13 is a development
version after all. It could easily be reverted if someone found an issue with
it. But it's your call.

___

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 #14503] Player often can't see his own shadows and nightgaunts

[Dan Gerhards]

Follow-up Comment #22, bug #14503 (project wesnoth):

I wonder if the difference is in the way our operating systems handle
translucent pixels. The game would use them of course, but screenshots
wouldn't actually have any.

Flipping it around was not a bad idea. I think it is an improvement, so let's
do it. Can we also put this into the nightguant's .cfg file? It should be
commented out for now, but then it would be ready to go when the unit has more
frames.

I also experimented with making [hides] less aggressive in the engine. I
raised it by 0.1 drawer.cpp. The difference isn't noticeable for other units,
but you can see the difference in the shadow at its lowest point. The claws
and hood in particular are a little more visible now. (Image attached.)

(file #29929)
___

Additional Item Attachment:

File name: shadow_in_cave_2.png   Size:61 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 #14503] Player often can't see his own shadows and nightgaunts

[Dan Gerhards]

Follow-up Comment #20, bug #14503 (project wesnoth):

I did a clean, up-to-the-minute build, and I still see the same thing as
before. I not sure I can explain what's going on, but the shadow is easier to
see when it's animated. I bet if you took a couple screenshots (to freeze the
motion) you would get one like mine.

"Even your level 1 Ghost...looked quite faint." Yeah. Maybe we ought to make a
separate standing animation for ghosts for use in cave terrains.

___

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 #25641] Turning on/off standing animations doesn't work correctly

[Dan Gerhards]

URL:
  

 Summary: Turning on/off standing animations doesn't work
correctly
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Mon 10 Apr 2017 08:45:00 AM PDT
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.7+dev
Operating System: Linux

___

Details:

Go to display preferences, and deselect "Show unit standing animations." When
you return to the game, the animations continue playing. They don't actually
stop until the unit is animated again. That means you can stop them by just
selecting a unit, but you would still have to click on each unit to have the
effect you wanted. Turning the option back on works the same way.




___

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 #14503] Player often can't see his own shadows and nightgaunts

[Dan Gerhards]

Follow-up Comment #18, bug #14503 (project wesnoth):

Here's a savefile. There are two shadows here, and they're both basically
invisible for part of the animation cycle. (I had disabled ellipses in the
screenshot.)

(file #29920)
___

Additional Item Attachment:

File name: SotA-North_Knalga_Turn_7_(shadow).gz Size:73 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 #14503] Player often can't see his own shadows and nightgaunts

[Dan Gerhards]

Follow-up Comment #16, bug #14503 (project wesnoth):

Okay, that's a lot better. You can see it well enough on most terrains. It's
still troublesome on some gray backgrounds though, like cave hills. (Image
attached.) It's not a common situation though, so maybe all we need to do is
tweak the animation timing so it spends less time at its most transparent
phase.

(file #29917)
___

Additional Item Attachment:

File name: shadow_in_cave.png Size:52 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 #25626] UtBS: Moving Kaleh hangs the game

[Dan Gerhards]

URL:
  

 Summary: UtBS: Moving Kaleh hangs the game
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Tue 28 Mar 2017 12:33:43 AM PDT
Category: Bug
Severity: 4 - Important
Priority: 5 - Normal
  Item Group: Campaign
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.13.7+dev
Operating System: Linux

___

Details:

I'm having trouble figuring out the exact trigger for this bug, but it does
involve illumination (provided by sun sylphs), and probably the scenario
Blood_is_Thicker_Than_Water. It can be reliably reproduced by moving Kaleh
from one illuminated hex to another hex illuminated by the same sylph, but
only on this scenario (so far). It only affects Kaleh, so his "support"
ability might be connected. Running from the console doesn't produce an error
message.

I have provided a save. Moving Kaleh to any hex adjacent to either sylph in
front of him causes the game to freeze. Moving to most other hexes works fine,
but I noticed that 35,30 also causes the crash. (Some of these moves trigger a
dialog too, but it hangs with or without that, so it's probably not
important.)



___

File Attachments:


---
Date: Tue 28 Mar 2017 12:33:43 AM PDT  Name:
UtBS-Bug_is_Thicker_than_Water-Turn-10.bz2  Size: 72kB   By: beetlenaut



___

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 #14503] Player often can't see his own shadows and nightgaunts

[Dan Gerhards]

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

All right, sorry. I'm just frustrated because I reported this problem more
than seven years ago.

___

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 #14503] Player often can't see his own shadows and nightgaunts

[Dan Gerhards]

Follow-up Comment #10, bug #14503 (project wesnoth):

The problem was never that the unit is *always* invisible, but that it's
invisible a lot of the time. That's still true, so it's not, in fact, fixed.

You said you're open to a better idea, but you also said, "perhaps the
translucency shouldn't be cranked up so high." That *was* a better idea! Let's
do that. You also said there would be no problem if we treated it like the
nightgaunt and gave it a constant translucency. That was another better idea!
We could do that too. But blinking on and off, in my opinion, is totally out
of the question.

___

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 #25177] Loading text not cleared properly

[Dan Gerhards]

Follow-up Comment #10, bug #25177 (project wesnoth):

Yes, installing SDL 2.0.4 corrects the problem. (Thanks guys.) So the bug can
be fixed by just requiring that for Linux builds.

___

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 #25177] Loading text not cleared properly

[Dan Gerhards]

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

Actually, no, it doesn't happen on the 1.13.5 release.

As far as SDL2 2.0.4 goes, it's not available through my package manager, so
installing it could end up being a chore. I might not have time to try it
before the weekend.

___

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 #25177] Loading text not cleared properly

[Dan Gerhards]

Update of bug #25177 (project wesnoth):

 Release: 1.13..5+dev => 1.13.5+dev 

___

Follow-up Comment #3:

The game loading screen does have a black background, but the campaign loading
screen doesn't. It sounds like it is supposed to, but I didn't edit anything.
Maybe this is some upstream display issue, except that the game seems to be
working right other than that; I can change resolutions and window size
without trouble, and move in and out of campaigns and scenarios. I don't have
any other problems on my system either. I have both libSDL and libSDL2, but we
are using SDL2 now right? These are the versions of those libraries I have:
libSDL2: 2.0.3
libSDL2_gfx: 1.0.1
libSDL2_image: 2.0.0
I'm using KDE 4.14.9, which is not bleeding edge in any way.

I wiped out the git repository and recloned it. I erased my savegames and
preferences too, and I still see the same behavior. I'm willing to believe
that the problem is on my end, but I would like to know where.

___

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 #25178] Recall dialog reordered every time it is seen

[Dan Gerhards]

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

It didn't occur to me to search in feature requests. Since this is a
regression from 1.12, it seems pretty clear to me that it should be classified
as a bug--at least this part of it.

___

Reply to this item at:

  

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


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

[Wesnoth-bugs] [bug #25179] Right-click menu grows longer and longer

[Dan Gerhards]

URL:
  

 Summary: Right-click menu grows longer and longer
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Thu 13 Oct 2016 02:05:46 AM PDT
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.5+dev
Operating System: Linux

___

Details:

When playing with debug on, "Kill Unit" shows up in the right-click menu. Then
its hotkey is listed, then a blank hotkey is listed a number of times.
Sometimes the number of extra hotkey entries grows. I'm not sure what exactly
causes the list to get longer, but loading a savefile seems to cause it pretty
reliably. The extra entries are retained on the next load of a savefile too.
Since only "Kill Unit" is affected, this only applies in debug mode, but
turning it off and back on doesn't clear the list.



___

File Attachments:


---
Date: Thu 13 Oct 2016 02:05:46 AM PDT  Name: kill_problem.png  Size: 13kB  
By: beetlenaut



___

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 #25178] Recall dialog reordered every time it is seen

[Dan Gerhards]

URL:
  

 Summary: Recall dialog reordered every time it is seen
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Thu 13 Oct 2016 01:19:49 AM PDT
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: Linux

___

Details:

The recall dialog starts out with the units in a seemingly random order.
(Probably it's just ordered by something unhelpful like internal ID.) You can
choose an order like XP or Level, but the order is reset to the default one
every time you bring up the dialog. The severity is not set at minor because
you have to deal with it constantly making it more annoying than it sounds.




___

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 #25177] Loading text not cleared properly

[Dan Gerhards]

URL:
  

 Summary: Loading text not cleared properly
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Thu 13 Oct 2016 01:03:55 AM PDT
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..5+dev
Operating System: Linux

___

Details:

When a campaign is loaded or the game is loaded for the first time, text
appears showing what exactly is happening. The text is never erased though, so
every string stacks on the previous one creating a mess. The attached .png
should make this clear.



___

File Attachments:


---
Date: Thu 13 Oct 2016 01:03:55 AM PDT  Name: text_problem.png  Size: 189kB  
By: beetlenaut



___

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 #24937] Problems with loading/deleting file names with spaces

[Dan Gerhards]

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

I am using Linux, and I am seeing the same 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 #25146] Crash to desktop when campaigns selected

[Dan Gerhards]

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

It works for me now too.

___

Reply to this item at:

  

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


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

[Wesnoth-bugs] [bug #25146] Crash to desktop when campaigns selected

[Dan Gerhards]

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

Maybe, but the report for bug #24937 says that Linux is not affected, and
that's what I am using. Also, this is a crash to the desktop instead of the
message about a corrupted save. It _may_ have the same root cause, but I'm not
convinced that it's a duplicate yet.

___

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 #25146] Crash to desktop when campaigns selected

[Dan Gerhards]

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

I found the save that causes the problem, and it seems to be the name of the
file that's at fault. It's a replay that I downloaded from the forums. I
already had a save of that name when I downloaded the replay, so the browser
added " (1)". Apparently the space in the name causes the crash.

___

Reply to this item at:

  

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


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

[Wesnoth-bugs] [bug #25146] Crash to desktop when campaigns selected

[Dan Gerhards]

URL:
  

 Summary: Crash to desktop when campaigns selected
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Mon 03 Oct 2016 11:15:53 AM PDT
Category: Bug
Severity: 5 - Blocker
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: Linux

___

Details:

The game instantly crashes to the desktop when the campaign button or its
hotkey is pressed on the main screen. This has been happening for a couple
weeks, but I assumed it was obvious enough that it would be fixed quickly. It
must not be happening to everyone though. Running from the terminal shows this
error:

Caught general exception:
Failed to convert string "" to type CAMPAIGN_TYPE





___

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 #14503] Player often can't see his own shadows and nightgaunts

[Dan Gerhards]

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

True. As you mentioned, this issue was pointed out seven years ago, and things
have changed since then. The two units were redesigned, and the Nightgaunt had
all its animation removed. Now it functions better as a game unit (though I
expect it will get the same animation back eventually and go mostly-invisible
again). So, the title of this bug report is no longer 100% accurate, but the
problem still exists.

Couldn't we just add a condition to the dimming code used for hidden units
causing the code to ignore Shadows and Nightgaunts?

___

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 #21336] Visual problems with halos on edge

[Dan Gerhards]

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

Yes, this still happens on 1.13.5. I can't help you with reproducing it
because it *always* happens on my machine. The window size doesn't matter. I
tried a small window, a large window, maximized, and full screen mode. It
doesn't matter how I scroll either: arrow keys, mouse wheel, center button. I
uploaded a new image that shows more of the behavior. Maybe it will help.

(file #28540)
___

Additional Item Attachment:

File name: halo problem 2.jpg Size:115 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 #22537] Wrong image in help

[Dan Gerhards]

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

 Summary: Wrong image in help
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Wed 27 Aug 2014 11:57:52 AM PDT
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.11.16
Operating System: Linux

___

Details:

In help, the Gameplay--Time of Day section shows the image for dawn where it
should show the one for second watch.




___

Reply to this item at:

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

___
  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 #22206] Tunnel problem causes lua errors, and bad surprise for the player

[Dan Gerhards]

Update of bug #22206 (project wesnoth):

Severity:  3 - Normal = 4 - Important  
 Release: 1.11.15 = 1.11.16
 Summary: Unreachable hexes through a tunnel are shown as
reachable = Tunnel problem causes lua errors, and bad surprise for the player

___

Follow-up Comment #1:

Every time the AI tries to use a tunnel with a unit stopped at the target end,
the screen gets covered with error messages, including one asking the user to
report the problem to the forums. This is a pretty bad problem for my
campaign, and I'm getting bug reports about it, so I'm moving the severity up.

___

Reply to this item at:

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

___
  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 #16582] WML control of level-up dialog

[Dan Gerhards]

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

I want to change the title, yes, but I also want to able to raise the
advancement dialog in an [event], without a unit having to gain any
experience. For that reason, we have to have a way to choose the unit the
dialog applies to.

___

Reply to this item at:

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

___
  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 #14503] Player often can't see his own shadows and nightgaunts

[Dan Gerhards]

Update of bug #14503 (project wesnoth):

Category: Feature Request = Bug
 Summary: Make player's shadows and nightgaunts more visible
= Player often can't see his own shadows and nightgaunts

___

Follow-up Comment #2:

I'm changing this to a bug, because being able to see my own units is not
really a new feature.

___

Reply to this item at:

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

___
  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 #22250] Using no_leader=yes causes 100% CPU usage

[Dan Gerhards]

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

In 1.11.16 I can't reproduce this bug any more. It seems to be fixed. Also
rather puzzling, unless you made some progress.

___

Reply to this item at:

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

___
  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 #21335] [delay] ignores acceleration

[Dan Gerhards]

Update of bug #21335 (project wesnoth):

Category: Feature Request = Bug
 Summary: Make delay proportional to acceleration = [delay]
ignores acceleration

___

Follow-up Comment #2:

No, it definitely doesn't work. It seems like it _is_ intended to, so that
makes this a longstanding bug instead of a feature request.

You can see an example of this in the first scenario of HttT, because the
macro that makes a signpost blink uses [delay] for its timing. Watch it at
acceleration 1 and 16. (You can skip all the dialog.) The difference should be
obvious, but actually, the signpost will blink at the same speed.

___

Reply to this item at:

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

___
  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 #22250] Using no_leader=yes causes 100% CPU usage

[Dan Gerhards]

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

(Sorry for the slow response--I've been out of town with no Internet.)

I did what you suggested. The backtrace looks like this every time:

#0  0x77b5a685 in ?? () from /usr/lib64/libSDL-1.2.so.0
#1  0x77b71152 in SDL_LowerBlit () from /usr/lib64/libSDL-1.2.so.0
#2  0x77b71357 in SDL_UpperBlit () from /usr/lib64/libSDL-1.2.so.0
#3  0x00e5bf14 in display::drawing_buffer_commit() ()
#4  0x00e64bab in display::draw(bool, bool) ()
#5  0x009db45a in controller_base::play_slice(bool) ()
#6  0x00c91ccd in playsingle_controller::play_human_turn() ()
#7  0x00c90309 in playsingle_controller::play_side(unsigned int, bool)
()
#8  0x00c9095e in playsingle_controller::play_turn(bool) ()
#9  0x00c928d0 in
playsingle_controller::play_scenario(std::pairconfig::const_child_iterator,
config::const_child_iterator const, bool) ()
#10 0x00c88512 in play_game(game_display, game_state, config const,
io_type_t, bool, bool, bool) ()
#11 0x00a7c865 in
game_controller::launch_game(game_controller::RELOAD_GAME_DATA) ()
#12 0x007286d6 in do_gameloop(int, char**) ()
#13 0x0070b6f2 in main ()


So, the loop seems to be in SDL. (The exact memory location in #0 varies, but
not by much.) With that in mind, I tried running at a lower resolution, and
the problem did not occur. The CPU was not overloaded, and stopping the
program with gdb always gave me a location in nanosleep, which sounds normal.

All I do to reproduce this is to load the scenario, but I usually run BfW at
2560 x 1440, and apparently that's part of the problem.

___

Reply to this item at:

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

___
  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 #22306] move_unit moves a unit even when it shouldn't

[Dan Gerhards]

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

 Summary: move_unit moves a unit even when it shouldn't
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Thu 10 Jul 2014 07:16:07 PM PDT
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.11.15
Operating System: Linux

___

Details:

If you use [move_unit] on a unit that happens to already be at the target
location, it seems like it shouldn't move. Instead, it does move one hex to
the NW. I assume this is because the target location is seen to be
occupied--by the unit itself.




___

Reply to this item at:

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

___
  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 #22215] Items in time_area change color with wrong time of day

[Dan Gerhards]

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

 Summary: Items in time_area change color with wrong time of
day
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Wed 18 Jun 2014 12:41:54 AM PDT
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.11.15
Operating System: Linux

___

Details:

If you define a time_area in a scenario and then place an item in that area,
the item will change color according to the main schedule, not the time area.
This results in things like underground items getting bright and orange when
it is day outside.




___

Reply to this item at:

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

___
  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 #22205] enter_hex and exit_hex events keep units from moving

[Dan Gerhards]

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

 Summary: enter_hex and exit_hex events keep units from moving
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Sun 15 Jun 2014 01:31:39 PM PDT
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.15
Operating System: Linux

___

Details:

If there is an event with name=exit_hex in a scenario file, units can't move
in that scenario. There don't need to be any actions in the event; just the
name= line is enough. If you select a unit, then click on a hex it can reach,
the unit is immediately deselected without having moved. Using an event with
name=enter_hex is different in that the selected unit moves one hex and is not
deselected afterwards, but it seems unlikely to be two separate bugs. This
affects AI units as well.




___

Reply to this item at:

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

___
  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 #22206] Unreachable hexes through a tunnel are shown as reachable

[Dan Gerhards]

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

 Summary: Unreachable hexes through a tunnel are shown as
reachable
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Sun 15 Jun 2014 04:36:55 PM PDT
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.15
Operating System: Linux

___

Details:

Hexes reachable through tunnels are all highlighted as expected, but in the
current implementation, a unit can't actually use the tunnel in some cases. In
the attached image and scenario file, there is a bidirectional tunnel
connecting the craters. You can select the saurian, then click on the swamp.
It moves through the tunnel and reaches the swamp as expected. But, if you
select the scout and click on the forest, it doesn't work. The scout moves to
the first crater, then an error message pops up saying the tunnel is being
blocked (by the mage)--though we know it's still open in the other direction.
Even worse, this move can't be undone! That's a nasty, un-fixable surprise for
the player. Also, if a micro_ai tries to send the scout through this tunnel,
it will spray lua errors across the screen. For more fun, try planning mode.

The simplest way to fix this is to mark hexes at the other side of the tunnel
as unreachable if a unit is there, but that doesn't make sense. Units on the
same side can move through each other in all other cases, so they should
definitely be able to do so in this case as well. For some uses, it might be
desirable to have units be able to block a tunnel (in one or both directions),
but that would still be possible with a few moveto events.



___

File Attachments:


---
Date: Sun 15 Jun 2014 04:36:55 PM PDT  Name: tunnel_test.jpg  Size: 82kB   By:
beetlenaut

http://gna.org/bugs/download.php?file_id=21048
---
Date: Sun 15 Jun 2014 04:36:55 PM PDT  Name: tunnel_test.cfg  Size: 792B   By:
beetlenaut

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

___

Reply to this item at:

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

___
  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 #22097] NR: White mage can vanish

[Dan Gerhards]

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

 Summary: NR: White mage can vanish
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Wed 28 May 2014 02:09:15 AM PDT
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group: Campaign
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.11.15
Operating System: Linux

___

Details:

If one of the immortal white magi is on the north or west edge of the map when
the other dies, the game will try to unstore the dead mage on a border hex.
The mage will not reappear because the location is invalid.




___

Reply to this item at:

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

___
  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 #22088] Disappearing units in the tutorial

[Dan Gerhards]

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

In regular campaigns, _all_ enemy units disappear if Skip AI moves is
selected in preferences. The units continue to function like the invisible
wolves, so this is probably caused by the same bug.

___

Reply to this item at:

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

___
  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 #22090] Village count incorrect after map resize

[Dan Gerhards]

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

 Summary: Village count incorrect after map resize
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Sun 25 May 2014 09:30:39 PM PDT
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group: Editor
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.11.15
Operating System: Linux

___

Details:

When you resize the map in the editor, the village count at the top of the
screen is not updated. If villages were lost in the resize, the count will be
incorrect.




___

Reply to this item at:

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

___
  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 #21285] Undo command fires an event

[Dan Gerhards]

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

I assumed that redo events actually were the same as regular actions.
Apparently we would need a redo event too. (In most cases, it would just fire
the original moveto event so that the same actions would occur. The redo event
would have to store the unit for that to work.)

I could just disallow undo, but the case I had in mind was a unit ability.
Some UMC authors have, in fact, disallowed undo for scenarios or entire
campaigns in order to use an ability like that. However, from the player's
standpoint, it seems like a frustrating bug. I'm not willing to do that to a
user, so I gave up on my idea instead.

___

Reply to this item at:

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

___
  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 #21330] Cannot select a unit with the mouse

[Dan Gerhards]

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

I'm on the dev mailing list, but don't remember any discussion about this, and
the archives don't seem searchable. Can you tell me where to look? I'm trying
to figure out what the advantages are and how to reliably access the
right-click menu.

___

Reply to this item at:

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

___
  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 #21357] Can't move with left click

[Dan Gerhards]

Update of bug #21357 (project wesnoth):

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

___

Follow-up Comment #1:

Apparently, this is the intended behavior now. I didn't get the memo. It
definitely needs to be explained to players in a prominent message, but it's
not a bug, so I'm closing this.

___

Reply to this item at:

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

___
  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 #21357] Can't move with left click

[Dan Gerhards]

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

 Summary: Can't move with left click
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Fri 20 Dec 2013 03:12:21 AM PST
Category: Bug
Severity: 5 - Blocker
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.7+dev
Operating System: Linux

___

Details:

If I left-click on a unit, then left-click on a target hex, the target hex
lights up, as well as any unit that can reach it (on any side!), but no unit
moves. If I am in planning mode, all of my units that can reach the hex are
scheduled to go there, but there is no way to make them actually move. If I
select a unit and _right-click_ on a hex, the unit will move correctly, but
the right-click menu is inaccessible, and there seems to be no way to deselect
the unit other than moving it.

Resetting the hotkeys doesn't help.

Everything works fine in ebe2b44, but that is the latest commit I know of that
works.

This is similar to bug #21311, but this one has some different behavior, and
the workaround for that one isn't helping. Also, 21311 is apparently fixed.




___

Reply to this item at:

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

___
  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 #21336] Visual problems with halos on edge

[Dan Gerhards]

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

I just discovered something: It only happens when Wesnoth is maximized. Did
you try it that way?

I didn't bother making a test scenario because it seemed so easy to reproduce.
Just stick a MOL on the edge of a map and scroll with the mouse wheel. (That's
more reliable than the keyboard.)

___

Reply to this item at:

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

___
  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 #21336] Visual problems with halos on edge

[Dan Gerhards]

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

distro: openSUSE 13.1 (latest)
architecture: x86_64
desktop: Plasma (KDE)
window manager: KWin (default)
resolution: 2560x1440
animations: everything except haloing effects turned off in display settings

I had animations turned on, but they're off now, and I still see the same
effect. I also tried turning off desktop compositing, but that didn't help
either.

___

Reply to this item at:

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

___
  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 #21330] Cannot select a unit with the mouse

[Dan Gerhards]

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

Should I reopen bug #21311, change the status of this one, or create a new bug
report for the current broken behavior?

___

Reply to this item at:

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

___
  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 #21340] Editor-generated .cfg files can break multiplayer

[Dan Gerhards]

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

 Summary: Editor-generated .cfg files can break multiplayer
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Wed 11 Dec 2013 01:17:34 PM PST
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.11.7+dev
Operating System: Linux

___

Details:

To reproduce: Open the map editor. Add a side, then add an Ancient Lich to the
map. Save the map and exit the editor. Click on Multiplayer--Local Game. You
get an error message, and are returned to the main screen:

Unterminated quoted string, value '
' at unknown:354

The line number points to this line in the new map.cfg file:

  _

Special Notes: +

The string _is_ terminated, but there is a line break first, which seems to be
causing the error message.

Playing or loading a campaign does not cause this error. An Ancient Lich in
the map file does, but an Elvish Marksman does not, despite having the same
Special Notes lines in its description.



___

File Attachments:


---
Date: Wed 11 Dec 2013 01:17:34 PM PST  Name: test.map  Size: 829B   By:
beetlenaut

http://gna.org/bugs/download.php?file_id=19453
---
Date: Wed 11 Dec 2013 01:17:34 PM PST  Name: test.map.cfg  Size: 15kB   By:
beetlenaut

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

___

Reply to this item at:

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

___
  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 #21330] Cannot select a unit with the mouse

[Dan Gerhards]

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

I can select a unit with a left-click now, but a second click doesn't move the
unit. It leaves the unit's hex and the target hex highlighted (or more
accurately, darkens all the other highlighted hexes), but does nothing else.
It seems that this bug is solved for me, but not bug #21311.

___

Reply to this item at:

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

___
  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 #21330] Cannot select a unit with the mouse

[Dan Gerhards]

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

I just discovered that I *can* move by selecting a unit with a left-click, and
clicking on the target hex with a right-click. That isn't the expected
behavior now, is it?

___

Reply to this item at:

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

___
  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 #21331] Walking corpses are unknown units

[Dan Gerhards]

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

I probably is a duplicate. I hadn't noticed any other units it was happening
to, so I searched for a bug involving walking corpses. I should have searched
for unknown unit as well.

___

Reply to this item at:

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

___
  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 #21335] Make delay proportional to acceleration

[Dan Gerhards]

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

 Summary: Make delay proportional to acceleration
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Sat 07 Dec 2013 05:53:59 PM PST
Category: Feature Request
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.7+dev
Operating System: Linux

___

Details:

Delay is usually used to time animations that don't involve units. Those
animations only look good for a narrow range of accelerations. They are
usually too slow or too fast. I would like a key for delay called
proportional that makes the delay timed to normal speed. If the player is
using double speed, the delay is cut in half and so on.

Alternatively, allowing the author to access the acceleration currently being
used would make this possible to write as a macro, and may have other uses as
well.




___

Reply to this item at:

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

___
  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 #21336] Visual problems with halos on edge

[Dan Gerhards]

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

 Summary: Visual problems with halos on edge
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Sat 07 Dec 2013 09:54:51 PM PST
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.11.7+dev
Operating System: Linux

___

Details:

A halo that extends into the border of the map leaves copies of itself behind
as you scroll the map. Part of the normal halo also detaches if you use the
keys instead of the mouse scroll wheel.



___

File Attachments:


---
Date: Sat 07 Dec 2013 09:54:51 PM PST  Name: halo problem.jpg  Size: 38kB  
By: beetlenaut

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

___

Reply to this item at:

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

___
  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 #21331] Walking corpses are unknown units

[Dan Gerhards]

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

 Summary: Walking corpses are unknown units
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Thu 05 Dec 2013 10:48:17 PM PST
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Units
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.11.7+dev
Operating System: Linux

___

Details:

You can use the help system to call up a walking corpse and view the stats on
it, but that is the only way to view them. Using a right-click to access the
unit description doesn't work, and neither does selecting Profile in the
recruit dialog, or clicking on the unit's name in the sidebar. In those cases,
you get a help screen with the message: This unit is unknown for the
moment Using :discover doesn't have any effect.




___

Reply to this item at:

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

___
  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 #21330] Cannot select a unit with the mouse

[Dan Gerhards]

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

This is not the same as bug #21311, but it is the same as the bug mentioned in
the comments for that one. It is partially resolved by resetting the hotkeys
to their defaults like it says in those comments. This is not a complete
workaround because after that fix, you cannot unselect a unit! A right-click
should do that, but instead, a right click causes the unit to move.

___

Reply to this item at:

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

___
  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 #21298] Minimap shows invisible overlays

[Dan Gerhards]

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

 Summary: Minimap shows invisible overlays
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Sat 23 Nov 2013 05:08:35 PM PST
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.7+dev
Operating System: Linux

___

Details:

Impassible and unwalkable overlays are visible in the map editor, but not in
the game. However, both overlays show up as black holes in the minimap.




___

Reply to this item at:

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

___
  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 #21284] Clicking Save map spawns a unit

[Dan Gerhards]

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

 Summary: Clicking Save map spawns a unit
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Tue 19 Nov 2013 07:51:51 AM PST
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.11.7+dev
Operating System: Linux

___

Details:

Clicking Save map in the editor with the unit tool selected creates a unit
on the hex underneath the file menu. Sometimes it deletes the last unit placed
as well.

To reproduce: Create a side. Select the unit tool, and add a unit to the map.
Select Save map as from the file menu. (This should work normally.) Add
several more units, then click on Save map from the file menu. I have seen
this work normally once, but usually it triggers the bug.

Workaround: Press Ctrl^S instead of using the menu.




___

Reply to this item at:

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

___
  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 #21285] Undo command fires an event

[Dan Gerhards]

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

 Summary: Undo command fires an event
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Tue 19 Nov 2013 09:18:44 AM PST
Category: Feature Request
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.7+dev
Operating System: Linux

___

Details:

Currently, there is no way to detect that a user has hit undo. That means that
no ability or effect that modifies the game state with a moveto event can
allow the user to undo the move. On the other hand, if the command could be
detected, it would be possible for the author to reset the game state
afterward.

I would like an event type named user undo or something similar that detects
that command. In order to be more useful, it should store the unit that was
un-moved and the hex it came from, but that's not entirely necessary.




___

Reply to this item at:

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

___
  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 #21285] Undo command fires an event

[Dan Gerhards]

Update of bug #21285 (project wesnoth):

Severity:  3 - Normal = 1 - Wish   


___

Reply to this item at:

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

___
  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 #21282] Terrain palette images missing

[Dan Gerhards]

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

 Summary: Terrain palette images missing
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Sun 17 Nov 2013 11:54:30 PM PST
Category: Bug
Severity: 4 - Important
Priority: 5 - Normal
  Item Group: Editor
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.11.7+dev
Operating System: Linux

___

Details:

Every terrain in the editor palette shows Image not found instead of the
terrain image. If you run from the terminal, you get a bunch of messages
showing incorrect paths:
image for terrain : 'terrain/terrain/frozen/snow.png.png' not found




___

Reply to this item at:

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

___
  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 #19066] Most orcs do not attack in LoW:03_Kalian_under_Attack

[Dan Gerhards]

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

I had 13 mostly-level-1 units against 54 mostly-level-2 units. That seemed
like a huge advantage for the AI, which is why I thought it was broken when
the AI never attacked.

I was finally able to get the enemy to engage by putting lone units near
their keep, so I guess it might be working the way it's supposed to.

___

Reply to this item at:

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

___
  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 #19066] Most orcs do not attack in LoW:03_Kalian_under_Attack

[Dan Gerhards]

Update of bug #19066 (project wesnoth):

Severity:   4 - Important = 5 - Blocker
 Summary: Most orcs in LoW:03_Kalian_under_Attack do not
attack = Most orcs do not attack in LoW:03_Kalian_under_Attack

___

Follow-up Comment #1:

I'm upgrading this to blocker because it breaks an official campaign, and I
want to make sure it gets looked at before the stable release.

___

Reply to this item at:

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

___
  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 #19066] Most orcs in LoW do not attack

[Dan Gerhards]

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

 Summary: Most orcs in LoW do not attack
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Sun 27 Nov 2011 05:11:24 PM PST
Category: Bug
Severity: 4 - Important
Priority: 5 - Normal
  Item Group: Campaign
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.9.11
Operating System: Linux

___

Details:

The purple and gray leaders appear on turn 10. The wolves of purple's first
recruit attack the elves, but the rest of his recruits move near gray's keep
and stay there. The gray leader's units never move at all.




___

Reply to this item at:

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

___
  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 #19066] Most orcs in LoW:03_Kalian_under_Attack do not attack

[Dan Gerhards]

Update of bug #19066 (project wesnoth):

 Summary: Most orcs in LoW do not attack = Most orcs in
LoW:03_Kalian_under_Attack do not attack


___

Reply to this item at:

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

___
  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 #19067] Wrong leader controllable in LoW:03_Kalian_under_Attack

[Dan Gerhards]

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

 Summary: Wrong leader controllable in
LoW:03_Kalian_under_Attack
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Sun 27 Nov 2011 05:36:58 PM PST
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group: Campaign
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.9.11
Operating System: Linux

___

Details:

You can right click on a location to ask El_Isomithir to move there. In the
right-click menu, El_Isomithir is identified as the leader of side 2. However,
Galtrid is also a leader, and the only one you must keep alive, so he should
be the one that you can control (he tends to attack from the water and die).




___

Reply to this item at:

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

___
  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 #18679] [ai] blocks are ignored

[Dan Gerhards]

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

Hmm. It still *doesn't* work for me in r51650. Could you replace the original
cfg (in AToTB) with the attached file, and see what happens? When I play, the
ai units, which should be restricted to the castle march right for the player
unless you remove the second [avoid].

(file #14263)
___

Additional Item Attachment:

File name: 01_Rooting_Out_a_Mage.cfg  Size:13 KB


___

Reply to this item at:

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

___
  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 #18679] [ai] blocks are ignored

[Dan Gerhards]

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

 Summary: [ai] blocks are ignored
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Sat 17 Sep 2011 04:02:33 PM PDT
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.9.9
Operating System: Linux

___

Details:

If there is more than one [ai] block in a side tag, all of them are ignored.
(This is true at least with [avoid]. Most other ai keys and tags have less
obvious effects, so it's hard to tell.)




___

Reply to this item at:

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

___
  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 #18330] Ignore All in replays doesn't work

[Dan Gerhards]

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

 Summary: Ignore All in replays doesn't work
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Mon 11 Jul 2011 11:05:41 AM PDT
Category: Bug
Severity: 2 - Minor
Priority: 3 - Low
  Item Group: Replays
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.9.7+svn
Operating System: Linux

___

Details:

If a replay is corrupted, you get a dialog box about the problem. In that
dialog is a checkbox that allows you to ignore any further problems. Checking
that box has no affect. Each problem still brings up that dialog, and the
Ignore All box is no longer checked.




___

Reply to this item at:

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

___
  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

[Dan Gerhards]

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

Here is an example. It should be immediately obvious where the path across
the water is, and it's not. This is from 05_Choice_in_the_Fog in TSG. This is
dawn, but it may be slightly worse during the day.

(file #12925)
___

Additional Item Attachment:

File name: water.png  Size:122 KB


___

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] [bug #17982] Make [delay] change according to acceleration

[Dan Gerhards]

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

 Summary: Make [delay] change according to acceleration
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Fri 01 Apr 2011 04:22:03 PM PDT
Category: Feature Request
Severity: 1 - Wish
Priority: 4
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.9.5
Operating System: Linux

___

Details:

Using a higher or lower acceleration has no affect on the [delay] tag, so
animations that use it always play at the same speed, no matter how fast or
slow the rest of the game is going. It looks awkward, and it can be annoying
to wait for animations to complete.

It would be better if the delay time scaled with the acceleration. The
implementation of the tag in WML would not have to change: The number of
milliseconds used in the tag could be understood to refer to normal speed, and
on other speeds, the milliseconds would automatically be adjusted.




___

Reply to this item at:

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

___
  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 #17773] Ability to simulate opponent's attacks

[Dan Gerhards]

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

 Summary: Ability to simulate opponent's attacks
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Sun 20 Feb 2011 07:29:26 PM PST
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.9.4
Operating System: Linux

___

Details:

It's very time consuming to calculate whether a unit of yours can be killed
or not by an enemy, but very simple for your opponent to figure that out. I
would like to see this changed.

Here is how it could work: You click on an enemy unit, and see the normal
attack triangle when you hover over your own unit. Clicking on your unit would
bring up the normal attack dialog, but without an OK button. The dialog
should reflect the time of day it will be on your opponent's turn. The
attached mock-up should make this all clear.



___

File Attachments:


---
Date: Sun 20 Feb 2011 07:29:26 PM PST  Name: simulate_attack_mockup.jpg 
Size: 292kB   By: beetlenaut

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

___

Reply to this item at:

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

___
  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 #17558] Turn off confirmation dialogs in debug mode

[Dan Gerhards]

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

 Summary: Turn off confirmation dialogs in debug mode
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Sun 23 Jan 2011 04:26:07 PM PST
Category: Feature Request
Severity: 1 - Wish
Priority: 3 - Low
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.9.3+svn
Operating System: Linux

___

Details:

When I'm debugging a scenario, the questions, Are you sure you want to
quit/end turn? come up all the time. The answer is always yes, so I suggest
turning them off for users in debug mode.




___

Reply to this item at:

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

___
  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 #16807] Option to execute all planned moves

[Dan Gerhards]

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

 Summary: Option to execute all planned moves
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Saturday 10/02/2010 at 16:43
Category: Feature Request
Severity: 1 - Wish
Priority: 5 - Normal
  Item Group: Whiteboard
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.9.1
Operating System: Linux

___

Details:

If you like all your planned moves, it is annoying to have to hit 'y'
repeatedly until they are all executed. How about Shift-y or Ctrl-y to
execute them all at once? Maybe one of those options should make it execute
up to the next attack and then stop.




___

Reply to this item at:

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

___
  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 #16791] DW - The Mage - bats never appear

[Dan Gerhards]

Update of bug #16791 (project wesnoth):

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


___

Reply to this item at:

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

___
  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 #16583] Skipping animations with [ESC]

[Dan Gerhards]

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

The worst offenders in cutscenes are [delay] and [move_unit_fake]. Those
two, at least, should be as easy to ignore as [message] is.

I know I can set the acceleration at maximum, and then set it back when I'm
through the opening, but that's annoying, and I have to remember that there
is a long delay in the upcoming scenario: You can't speed up the game
*during* the opening. (If you are running at 1.5x or 2x, holding down shift
won't help either.)

___

Reply to this item at:

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

___
  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 #16603] Capture villages with waypoints

[Dan Gerhards]

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

 Summary: Capture villages with waypoints
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Tuesday 08/31/2010 at 01:04
Category: Feature Request
Severity: 1 - Wish
Priority: 5 - Normal
  Item Group: User Interface
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.9
Operating System: Linux

___

Details:

Currently, setting waypoints in multiple villages just makes the unit move
through each of them. It would be more useful if the unit would *capture*
each of them. I can't think of a situation where you would want to put a
waypoint on an enemy village, but not want to capture it.




___

Reply to this item at:

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

___
  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 #16582] WML control of level-up dialog

[Dan Gerhards]

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

 Summary: WML control of level-up dialog
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Monday 08/30/2010 at 00:34
Category: Feature Request
Severity: 1 - Wish
Priority: 5 - Normal
  Item Group: WML
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.9
Operating System: Linux

___

Details:

It would be nice if we could use WML to bring up the dialog box that appears
when a unit levels up. We should be able to load it with whatever units we
need, and be able to change the text about the victorious unit. You can
fake this with [message] and [option], but it doesn't look as nice, and you
don't get the Profile button. The profile is very important if you've never
seen one of the units before--a common situation in UMC. I imagine something
like this:

[level_up_dialog]
[filter]
id=$unit.id
[/filter]
title= _ What kind of flying unit should $unit.name| become?
unit_types=Elvish Sylph, Dread Bat, Gryphon Rider
[/level_up_dialog]





___

Reply to this item at:

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

___
  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 #16584] Time of day doesn't change in time area.

[Dan Gerhards]

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

 Summary: Time of day doesn't change in time area.
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Monday 08/30/2010 at 00:54
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.9
Operating System: Linux

___

Details:

The main time for a scenario is {UNDERGROUND}, and a time_area sets part of
it to {DEFAULT_SCHEDULE}. However, the time area is always dusk.
The scenario is the first one in The Founding of Borstep. (On the 1.9 sever.)




___

Reply to this item at:

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

___
  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 #16148] Assertion failed: !wml_triggered

[Dan Gerhards]

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

This bug does not always occur. I was unable to create a save file that
causes it, but the one uploaded by gnombat does.

(In case it saves you some time: the bug is triggered by a [recall] tag at
line 657 in the attached cfg file.)

(file #9314)
___

Additional Item Attachment:

File name: 09_Dwarf_City.cfg  Size:17 KB


___

Reply to this item at:

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

___
  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 #15613] Tip of the day display issue

[Dan Gerhards]

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

 Summary: Tip of the day display issue
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Sunday 03/14/2010 at 03:46
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.7.14
Operating System: Linux

___

Details:

The last character in the source line is half missing.



___

File Attachments:


---
Date: Sunday 03/14/2010 at 03:46  Name: missing letter.png  Size: 18kB   By:
beetlenaut

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

___

Reply to this item at:

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

___
  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 #15226] Crash when saving in linger mode

[Dan Gerhards]

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

This one seems to do it every time. In case it matters, I compiled 1.7.12 for
myself.

@Anonymissimus
Actually, I hadn't realized that.

(file #7849)
___

Additional Item Attachment:

File name: NR-Breaking_the_Chains-crash.gz Size:47 KB


___

Reply to this item at:

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

___
  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 #15226] Crash when saving in linger mode

[Dan Gerhards]

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

 Summary: Crash when saving in linger mode
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Friday 01/29/2010 at 20:20
Category: Bug
Severity: 2 - Minor
Priority: 5 - Normal
  Item Group:  None of the others
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.7.12
Operating System: Linux

___

Details:

If you attempt to save a game in linger mode, BfW crashes as soon as you
enter the name, and the game is not saved. (This matters to a campaign
designer.) It worked fine in 1.7.8, but I don't know when it stopped working.




___

Reply to this item at:

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

___
  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 #15113] Units can talk in their own die events

[Dan Gerhards]

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

It sounds like this may be more trouble than its worth to change. Since the
behavior seems counterintuitive, I added a note to the wiki.

___

Reply to this item at:

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

___
  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 #15113] Units can talk in their own die events

[Dan Gerhards]

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

 Summary: Units can talk in their own die events
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Tuesday 01/12/2010 at 16:48
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.7.11
Operating System: Linux

___

Details:

A die event fires after the unit's death animation plays, and the unit
disappears. However, in the following code, the unit that triggered the event
can be the one who talks. Also, the ghost won't appear in the right place:

[event]
name=die

[filter]
side=2
[/filter]

[message]
side=2
message= _ You killed one of us!
[/message]

[unit]
type=Ghost
x=$unit.x
y=$unit.y
[/unit]
[/event]


As a workaround, you can add a [kill] tag to the die event:

[kill]
id=$unit.id
[/kill]

But that isn't obvious, and if it's necessary, it should happen internally.




___

Reply to this item at:

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

___
  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 #14969] Expressions with + fail

[Dan Gerhards]

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

I actually thought of that, but rejected it because the parentheses and
dollar sign didn't show up in the strings. I reasoned that the engine *was*
correctly treating those as operators. (I still don't understand what it's
doing with those characters.) Also, $(1+$x) concatenates, and $($x+1) returns
nothing. This seemed like a mistake.

___

Reply to this item at:

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

___
  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 #14925] UtBS: Dwarf tomb items not visible

[Dan Gerhards]

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

 Summary: UtBS: Dwarf tomb items not visible
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Saturday 12/12/2009 at 08:06
Category: Bug
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Campaign
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.7.9
Operating System: Linux

___

Details:

In scenario 06b, There should be a rune and a coffin or two. None of them are
there. (The associated events seem to work like they are supposed to.)

The problem seems to be in 06b_In_the_Domain_of_Dwarves.cfg starting with
line 402. The image locations are all bogus, and place the images off the
map. The rune should be at 45,21, and the first coffin at 49,24. I don't know
where the second coffin was supposed to go.




___

Reply to this item at:

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

___
  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 #14800] Allow changing of an ellipse

[Dan Gerhards]

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

Right. It no longer works.

There was a discussion on the forum about it where sapient suggested putting
in a feature request, which is why I did it that way. It's better for me if
it's supposed to work already.

http://www.wesnoth.org/forum/viewtopic.php?p=351168

___

Reply to this item at:

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

___
  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 #14800] Allow changing of an ellipse

[Dan Gerhards]

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

 Summary: Allow changing of an ellipse
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Saturday 11/21/2009 at 02:04
Category: Feature Request
Severity: 1 - Wish
Priority: 5 - Normal
  Item Group: WML
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.7.8
Operating System: Linux

___

Details:

I would like to be able to change a unit's ellipse. It used to work through
direct modification of the variable, but allowing an object to change it
would probably be better.

(I don't suppose the fact that it used to work gets us around the feature
freeze.)




___

Reply to this item at:

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

___
  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 #14795] Map editor and game show different tiles

[Dan Gerhards]

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

 Summary: Map editor and game show different tiles
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Thursday 11/19/2009 at 14:05
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.7.8
Operating System: Linux

___

Details:

Sometimes I move items around in the editor to get certain variations of
villages, mountain ranges, or whatever. That doesn't work any more because
the game and editor show different variations. The terrains are functionally
the same, but they look different. I would like them to look the same.

In case that isn't clear, I attached images of a section of a map in the
editor and when playing.



___

File Attachments:


---
Date: Thursday 11/19/2009 at 14:05  Name: different_variations.jpg  Size:
53kB   By: beetlenaut

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

___

Reply to this item at:

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

___
  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 #14796] Some waypoints ignored

[Dan Gerhards]

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

 Summary: Some waypoints ignored
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Thursday 11/19/2009 at 18:24
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.7.8
Operating System: Linux

___

Details:

When entering a multiple-turn command for a unit, you can set waypoints as
many turns in advance as you want, but all waypoints that would be reached
after the current turn are ignored. Only the final destination is saved.

If that was the intended behavior, this becomes a feature request. However,
if some waypoints are going to be ignored, they shouldn't be allowed to be
set.




___

Reply to this item at:

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

___
  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 #14768] In some cases, the AI does not recruit.

[Dan Gerhards]

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

 Summary: In some cases, the AI does not recruit.
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Sunday 11/15/2009 at 08:57
Category: Bug
Severity: 5 - Blocker
Priority: 5 - Normal
  Item Group: Artificial Intelligence
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.7.8
Operating System: Linux

___

Details:

It seems that the AI recruits just one type of unit for each usage. One type
of fighter, one archer, one scout, etc. If you disallow the unit it would
have recruited, the AI will stop recruiting that type. If it only had one
type available, it will stop recruiting altogether.

Example:
I modified the recruitment list of a scenario known to work: Rooting Out a
Mage from AToTB. I allowed Skeletons, Death Blades, and Revenants, all of
which are fighters. The AI only recruited Revenants. (I assume it evaluates
them as the best.) I then added the line, {LIMIT_CONTEMPORANEOUS_RECRUITS 2
Revenant 2}. It recruited two revenants, then stopped recruiting anything,
even though it had plenty of gold left, and two other units available.



___

File Attachments:


---
Date: Sunday 11/15/2009 at 08:57  Name: 1_Rooting_Out_A_Mage.cfg.gz  Size:
4kB   By: beetlenaut

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

___

Reply to this item at:

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

___
  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 #14765] Negative finishing gold is not added

[Dan Gerhards]

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

 Summary: Negative finishing gold is not added
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Saturday 11/14/2009 at 23:48
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.7.8
Operating System: Linux

___

Details:

You can end a scenario and get a message like this:
You will start the next scenario with -50 on top of the minimum defined
starting gold.

That's not actually true. When you finish with negative gold, you just start
the next level with the minimum. That message should be changed to:
You will start the next level with the minimum defined starting gold.

(If this would violate a string freeze, it would probably be better to just
remove the message altogether until it can be changed. No message is better
than an incorrect message.)




___

Reply to this item at:

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

___
  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 #14766] Wrong portrait for merman entangler

[Dan Gerhards]

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

 Summary: Wrong portrait for merman entangler
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Saturday 11/14/2009 at 23:55
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.7.8
Operating System: Linux

___

Details:

The merman entangler uses the hunter's portrait. It was supposed to share
with the netcaster instead.




___

Reply to this item at:

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

___
  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 #14653] Some dialog doesn't fit

[Dan Gerhards]

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

 Summary: Some dialog doesn't fit
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Saturday 10/31/2009 at 20:55
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.7.7
Operating System: Linux

___

Details:

Some dialog goes outside of its display area. You end up with a scroll bar
and an OK button below the dialog. I'm pretty sure the area only needs to
be three pixels larger to make it all fit (on my system at least). It would
also work to have the dialog wrap one letter earlier.



___

File Attachments:


---
Date: Saturday 10/31/2009 at 20:55  Name: scroll bar.png  Size: 219kB   By:
beetlenaut

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

___

Reply to this item at:

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

___
  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 #14591] Team color incorrect for loyal units

[Dan Gerhards]

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

 Summary: Team color incorrect for loyal units
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Saturday 10/24/2009 at 06:55
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.7.6
Operating System: Linux

___

Details:

In campaigns, the team color for loyal units shows up as brown instead of
red. This seems to be the case in all campaigns. This is only on the
sprites--ellipses are unaffected.

(Actually, this is kind of useful for keeping track of your loyal units, but
brown is already a color for another team.)



___

File Attachments:


---
Date: Saturday 10/24/2009 at 06:55  Name: TSG-Team_Color_Problem.gz  Size:
15kB   By: beetlenaut

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

___

Reply to this item at:

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

___
  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 #14599] Player notified when enemy is ambushed.

[Dan Gerhards]

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

 Summary: Player notified when enemy is ambushed.
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Sunday 10/25/2009 at 02:37
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.7.7
Operating System: Linux

___

Details:

The game puts up the Ambushed! notice when an enemy gets ambushed. Not only
that, but the event takes place in the fog. To see it, load the save file, and
end the turn. If you turn off the fog, you can see a dragoon get ambushed by
an elvish ranger on 70,18. (This happens almost every time.)



___

File Attachments:


---
Date: Sunday 10/25/2009 at 02:37  Name: Ambushed.gz  Size: 81kB   By:
beetlenaut

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

___

Reply to this item at:

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

___
  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 #14503] Make player's shadows and nightgaunts more visible

[Dan Gerhards]

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

 Summary: Make player's shadows and nightgaunts more visible
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Monday 10/12/2009 at 07:48
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: Units
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.7.6
Operating System: Linux

___

Details:

Shadows and nightgaunts are partly transparent, so when they are on your
side, and dimmed because they are hidden, they disappear entirely. About 75%
of the time, all you can see are the bars and orb. Just removing the extra
dimming would be enough--there is a hidden indicator on the sidebar, so the
information is still available.




___

Reply to this item at:

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

___
  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 #14227] BfW crashes when unit is created in presense of shroud

[Dan Gerhards]

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

 Summary: BfW crashes when unit is created in presense of
shroud
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Tuesday 09/01/2009 at 17:43
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.6.4
Operating System: Linux

___

Details:

This is an obscure one. It took me a long time to find a way to reproduce it
most of the time. I stripped down my campaign to about the minimum needed and
included it here.

To reproduce the crash, load up the Bug Test campaign. On the far right are
two goblins near wolves (which are just pictures). Move one of the goblins to
the wolf on 25,19. He is replaced by a wolf rider on the same hex. Move the
other goblin around on the grass until he is low on movement points. Use his
last movement point to capture the wolf on 26,19. He is replaced, then
Wesnoth crashes.

This seems to have something to do with the shroud. There is no crash when
you take out shroud=yes.

The code that creates the wolf rider is on line 210 of 01_New_Leader.cfg if
that helps.



___

File Attachments:


---
Date: Tuesday 09/01/2009 at 17:43  Name: bugtest.zip  Size: 4kB   By:
beetlenaut

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

___

Reply to this item at:

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

___
  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 #13504] Apparent engine bug in STARTING_VILLAGES macro

[Dan Gerhards]

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

The bug was in Showdown, the last scenario in the Northern Rebirth campaign.

___

Reply to this item at:

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

___
  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 #13505] NR: Recovered gold was not distributed on the last scenario

[Dan Gerhards]

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

I won't have time to replay the scenario for a while--at least a week.
However, I took a look at the diffs for the SVN revision and see two
problems. First, Anita is no longer set to side 1 in Get_The_Gold, so she
won't be recallable in Showdown.

Second, if Anita is not alive, you kill the rest of the elves, then, later,
check to see if Sisal is alive. She won't be.

(Thanks for preserving Anita's recall list. That was a major annoyance.)

___

Reply to this item at:

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

___
  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 #13504] NR: Elves don't own any villages

[Dan Gerhards]

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

 Summary: NR: Elves don't own any villages
 Project: Battle for Wesnoth
Submitted by: beetlenaut
Submitted on: Sunday 05/10/2009 at 20:04
Category: Bug
Severity: 4 - Important
Priority: 5 - Normal
  Item Group: Campaign
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 1.6.1
Operating System: Linux

___

Details:

At the start of the scenario, none of the villages by the elf's keep are
owned. They are supposed to be: I can see in the WML that there is a macro to
capture them all. It works for the other sides, but not side 9, so maybe this
is actually an engine bug.




___

Reply to this item at:

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

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


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